Mozilla believes that the web can displace proprietary, single-vendor stacks for application development.  To make open web technologies a better basis for future applications on mobile and desktop alike, we need to keep pushing the envelope of the web to include --- and in places exceed --- the capabilities of the competing stacks in question.

We also need a hill to take, in order to scope and focus our efforts.  Recently we saw the pdf.js [http://github.com/andreasgal/pdf.js/] project expose small gaps that needed filling in order for "HTML5" to be a superset of PDF.  We want to take a bigger step now, and find the gaps that keep web developers from being able to build apps that are --- in every way --- the equals of native apps built for the iPhone, Android, and WP7.

To that end, we propose a project we’re calling "Boot to Gecko" [http://wiki.mozilla.org/B2G] (B2G) to pursue the goal of building a complete, standalone operating system for the open web.  It’s going to require work in a number of areas.

* New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
* Privilege model: making sure that these new capabilities are safely exposed to pages and applications
* Booting: prototype a low-level substrate for an Android-compatible device;
* Applications: choose and port or build apps to prove out and prioritize the power of the system.

We will do this work in the open, we will release the source [http://github.com/andreasgal/B2G] in real-time, we will take all successful additions to an appropriate standards group, and we will track changes that come out of that process.  We aren't trying to have these native-grade apps just run on Firefox, we're trying to have them run on the web.

This project is in its infancy; some pieces of it are only captured in our heads today, others aren’t fully explored.  We’re talking about it now because we want expertise from all over Mozilla -- and from people who aren’t yet part of Mozilla -- to inform and build the project we’re outlining here.

brendan, cjones, gal, shaver

On 25 juil, 17:49, Andreas Gal <g...@mozilla.com> wrote:

Very very exciting!

--Tristan

Given this, thoughts about, or reactions, or possible work with to
Webian OS? (http://webian.org/ - built on Chromeless)

On Jul 25, 8:49 am, Andreas Gal <g...@mozilla.com> wrote:

Yay that's awesome!

Why not boot to a more conventional Linux stack? Android brings a lot
of baggage that's useful for building a mobile phone running J*va apps
but does less for bringing up a Gecko. Surely a straight-forward Linux
w/ X would be a simpler, more open way to implement a Gecko-OS.

Ian

This is fantastic!

On 2011-07-25, at 12:49, Andreas Gal wrote:

Why Android and not a PC to start with? Would it be easier? Fewer moving parts, fewer device unknowns? Is a PC-level device on the table as well?

I realize you might not have these answers just yet, but I'm curious and felt like asking. :)

--
  Rob "Scope Creep" Campbell
    - blog: http://antennasoft.net/robcee
    - twitter: http://twitter.com/robcee

As with ChromeOS and other such projects, we'll be looking all over
the place for both inspiration and collaboration.  We're really
focused on the handheld/tablet/mobile experience for this work, and it
looks like Webian is more aiming at the desktop.  It will great if
we're both successful!

Webian's experiences in building APIs for system services seem like a
great place to collaborate, too.

Mike

We might prototype some stuff on a PC, but the project is really about
the device space.  We had to pick somewhere, and this seems like where
the energy is best spent.

Desktop devices tend to be harder to get good open drivers for without
pulling in things like X, which we don't want to do.

Mike

On Jul 25, 10:19 am, Ian McKellar <ian.mckel...@rd.io> wrote:

We won't be taking any of that stuff, not to worry. Just the kernel
and device drivers.

Maemo is not making it.

These days the device makers are moving to Android. To get all the HAL
benefits,we want to reuse its lower layers.

All open source is a requirement in my view. We'll see how this goes.

/be

We intend to use as little of Android as possible, in fact.  Really,
we want to use the kernel + drivers, plus libc and ancillary stuff.
It's not likely that we'll use the Android Java-wrapped graphics APIs,
for example.  It's nice to start from something that's known to boot
and have access to all the devices we want to expose.  Maybe that's
not the right direction, though, so if someone wants to explore
another direction that'd be just fine.

Our experiences with performance and hardware acceleration on X
haven't been great, and it's a pretty heavyweight component to bring
in.  Are there good drivers for the hardware found in current phones
and tablets?

Mike

On Jul 25, 5:49 pm, Andreas Gal <g...@mozilla.com> wrote:

What about exposing the CPU, a la NativeClient?

- Bert -

Don't worry, mobile devices are not better for good open drivers, with
or without X. And you get additional fun from the lack of standards
on the hardware side...

Mike

On Jul 25, 10:29 am, Bert Freudenberg <ber...@gmail.com> wrote:

Those New Web APIs are for the standardized, portable content
languages (JS/HTML/CSS). We are not looking to run native code,
especially given the requirements for a new plugin API, complex
toolchain, etc. We're following NaCl, including the PNaCl work, but it
is not ready for prime time, and we'd have to spend a lot of people
and time integrating and tracking it. The opportunity cost on pushing
the open web standard is very high, at least for our community.

Google can much better afford to invest in NaCl, but that won't
necessarily make a standard. The toolchains and OSes are likelier to
support control-flow integrity enforcement in native code sooner than
the browser makers, IMHO.

/be

On 07/25/2011 01:29 PM, Bert Freudenberg wrote:

Pretty much every web API exposes the CPU (or GPU) to content, at some
level of abstraction.  Do you mind being a bit more specific about what
you want?

We have no plans to implement Native Client at this time.

Cheers,
Chris

 That's a great and ambitious goal, and in a shorter time frame I'm
exploring a less disruptive option:
Set fennec to run as your android homescreen, with the homescreen itself
implemented as a web app, using a couple of additional APIs :
- The openwebapps API (https://developer.mozilla.org/en/OpenWebApps/
The_JavaScript_API)
- An API to list/launch native android apps (based a cleaned up version
of http://dev.w3.org/2009/dap/app-launcher/)

 With this we can get android users to transition to a web-based solution
with not much risk : no need to change your ROM for instance.

 Fabrice

Awesome news, I recommend integrating BrowserID as well.[1]

[1]https://browserid.org/

On Jul 25, 2011, at 10:47 AM, Fabrice Desré wrote:

This is exactly our current starting point. We have a demo of this up and running.

A number of intermediate steps are possible. I am very interested in making a beefed up web stack with powerful local APIs available to users of existing devices. I think we can do this without distracting from the ultimate goal: breaking the stranglehold of proprietary technologies over the mobile device world.

Andreas

On Jul 25, 10:35 am, Brendan Eich <brendan.e...@gmail.com> wrote:

ChromeOS will be first, but Microsoft and even Apple may follow -- but
not with NaCl, rather their own equivalents. I don't expect any
standardization for a long, long time. The use-case will still be
downloading binary code, but safer code. It won't be schlepping big
gobs of x86 or even LLVM bitcode (still with machine dependencies)
around as if it were JS.

/be

Hi Brendan,

Am 25.07.2011 19:26, schrieb Brendan Eich:

This has some interesting implications for accessibility which I'll be
blogging about in the near future. Just an initial thought:

We would need the capability to install speech synths so blind users
could use a (yet to be written) extension/possibly part of the browser
that provides them speech feedback in all environments. For that,
whichever we include from Android, we'd need to make sure that the
speech services framework is part of that.

This is super exciting stuff, and I look forward to participating in
this process!

Marco

On 07/25/2011 02:16 PM, Marco Zehe wrote:

Speech synthesis is a capability we want to have, but it's not something
we necessarily need to import an android framework for.  Speech
synthesis can be implemented by web pages, today, using JavaScript and
audio APIs.  We definitely want to hear what the a11y requirements are
for this (and in general!) so we can figure out what the best
implementation might be.

Yes, please do.

Cheers,
Chris

On Jul 25, 10:49 am, Matthew <phillip...@gmail.com> wrote:

You bet!

/be

I'm very happy and excited to see this. Awesome! Thank you!

Just curious: Did you evaluate Meego kernel & Wayland in comparison to
Android kernel & Android graphics? Does Android win on driver
availability/quality alone or also on pure technical merit?

What do webOS and Chrome OS use for graphics? Do they ship X or
something that's not X, not Wayland and not the Android graphics layer?

--
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

We'll evaluate them, but for right now we want to take advantage of
the work we've already done (and are doing) on Android, and the ease
of getting devices that are known to work.  Specifically, we're
looking at Tegra 2 devices because they have hardware acceleration of
open audio/video formats, and they match what we've got automated
testing running on.

I'm not sure -- I don't believe that the graphics stack for ChromeOS
is open, but I might just have missed it browsing the code.  No idea
about WebOS either.

If people want to help identify other good OS/device combinations,
though, that would be welcome.  For now we're going to be doing just
enough work to get to booting to Gecko and then focus higher up the
stack to write the system services (dialer, camera app, etc.) as
locally-cached web applications.

Mike

On 7/25/2011 3:14 PM, Henri Sivonen wrote:

Very cool... especially as an old-time OS geek (Commodore Amiga OS
team/one-time-lead).

I'll say that it seems likely that future hardware will come with
drivers for Android (just talk to TI or other chipset makers; they're
pretty much all providing "base" Android ports for their mobile-capable
chipsets), which means access to all that hardware that's often has no
fully-open-source driver. (For example, code that drives the video codec
accelerators.)

--
Randell Jesup, Mozilla Corporation
Remove ".news" for personal email

On Jul 25, 1:23 pm, Mike Shaver <mike.sha...@gmail.com> wrote:

I don't know the current state of Android/x86 but wouldn't that also
be a good platform to develop on? It could be an easy way to bootstrap
this. Same Android layer, same Gecko code, lots of overlap with Fennec/
Linux. It would mean that we could hack on BootToGecko on a much
easier to handle environment that runs in VMWare of VirtualBox.

 S.

On Mon, Jul 25, 2011 at 3:30 PM, Stefan  Arentz <stefan.are...@gmail.com> wrote:

Depending on the state of Android/x86, that sounds very promising.
Does that work for Fennec stuff now?

Mike