Booting to the Web
Andreas Gal
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
Tristan Nitot - Mozilla
> 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.
Very very exciting!
--Tristan
Ian Bicking
Webian OS? (http://webian.org/ - built on Chromeless)
Ian McKellar
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
Yay that's awesome!
> * Booting: prototype a low-level substrate for an Android-compatible device;
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
Rob Campbell
On 2011-07-25, at 12:49, Andreas Gal wrote:
> * Booting: prototype a low-level substrate for an Android-compatible device;
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
Mike Shaver
> Given this, thoughts about, or reactions, or possible work with to
> Webian OS? (http://webian.org/ - built on Chromeless)
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
Mike Shaver
> 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?
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
Brendan Eich
> 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
We won't be taking any of that stuff, not to worry. Just the kernel
and device drivers.
> 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.
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
Mike Shaver
> 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.
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
Bert Freudenberg
> * 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
What about exposing the CPU, a la NativeClient?
- Bert -
Mike Hommey
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
Brendan Eich
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
Chris Jones
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
Fabrice Desré
> 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.
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
Matthew
Andreas Gal
On Jul 25, 2011, at 10:47 AM, Fabrice Desré wrote:
> On Mon, 25 Jul 2011 13:27:30 -0400, Mike Shaver wrote:
>
>> 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.
>
> 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/)
This is exactly our current starting point. We have a demo of this up and running.
>
> 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.
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
>
> Fabrice
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Brendan Eich
> 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.
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
Marco Zehe
Am 25.07.2011 19:26, schrieb Brendan Eich:
> On Jul 25, 10:19 am, Ian McKellar<ian.mckel...@rd.io> wrote:
>> 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
> We won't be taking any of that stuff, not to worry. Just the kernel
> and device drivers.
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
Chris Jones
> Hi Brendan,
>
> Am 25.07.2011 19:26, schrieb Brendan Eich:
>> On Jul 25, 10:19 am, Ian McKellar<ian.mckel...@rd.io> wrote:
>>> 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
>> We won't be taking any of that stuff, not to worry. Just the kernel
>> and device drivers.
> 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.
>
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.
> This is super exciting stuff, and I look forward to participating in
> this process!
Yes, please do.
Cheers,
Chris
Brendan Eich
> Awesome news, I recommend integrating BrowserID as well.[1]
>
> [1]https://browserid.org/
You bet!
/be
Henri Sivonen
> 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.
I'm very happy and excited to see this. Awesome! Thank you!
> * Booting: prototype a low-level substrate for an Android-compatible device;
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
hsiv...@iki.fi
http://hsivonen.iki.fi/
Mike Shaver
> 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?
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.
> What do webOS and Chrome OS use for graphics?
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
Randell Jesup
> On Mon, 2011-07-25 at 08:49 -0700, Andreas Gal wrote:
>> 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.
>
> I'm very happy and excited to see this. Awesome! Thank you!
Very cool... especially as an old-time OS geek (Commodore Amiga OS
team/one-time-lead).
>> * Booting: prototype a low-level substrate for an Android-compatible device;
>
> 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?
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
Stefan Arentz
> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcampb...@mozilla.com> 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?
>
> 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.
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.
Mike Shaver
> 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.
Depending on the state of Android/x86, that sounds very promising.
Does that work for Fennec stuff now?
Mike
Chris Jones
Sure, that's an option. Note that the android SDK includes an emulator
based on qemu, so running B2G/ARM builds on your desktop isn't
necessarily a problem (because of the emulator).
Cheers,
Chris
Mike Shaver
>
> On Monday, July 25, 2011 at 10:27 AM, Mike Shaver wrote:
>
>> Our experiences with performance and hardware acceleration on X
>> haven't been great
>
That's great, I should take another look. Thanks!
Mike
ya knygar
now a bit of criticism:
Tegra is an obvious choice for a start (But - nvidia often make the
closed, proprietary drivers, i wonder if they missed their usual
politics on Tegra..) - uprising mega-platform, performance is good
etc.
But:
>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
i understand that tweaking the gecko once for both Android and Android is cool,
but isn't there already enough of Android and it's SDK? aren't there
are pretty mature
https://secure.wikimedia.org/wikipedia/en/wiki/SHR_(operating_system)
and other variants, many other, more natural - GNU/Linux variants.
Could you, please, tell - when do you plan to evaluate these
non-Android variants?
So we could decide if the petition to Mozilla about non-Android OS is
appropriate now.
Mike Shaver
> i understand that tweaking the gecko once for both Android and Android is cool,
> but isn't there already enough of Android and it's SDK?
Apps won't use the Android SDK, they'll use current-and-future Web APIs.
> Could you, please, tell - when do you plan to evaluate these
> non-Android variants?
I don't know of any plans to evaluate SHR; I don't have any devices it
runs on, personally, and none of the ones listed in Wikipedia are very
interesting to target IMO. We have a lot of work to do even starting
from a working operating system. Adding OS-bringup to our plate isn't
really attractive to me at this time.
If you or someone else would like to evaluate SHR, on the other hand,
that would be welcome information. Just telling us that we shouldn't
look at Android is unlikely to be very effective, since that's where
we feel our work is best directed right now. Facts coming out of
evaluation of Android and other proposed platforms would be much more
influential, because they can actually help inform decisions.
Mike
Robin Berjon
On Jul 25, 2011, at 19:47 , Fabrice Desré wrote:
> - An API to list/launch native android apps (based a cleaned up version
> of http://dev.w3.org/2009/dap/app-launcher/)
I really don't think that using the App Launcher draft as any manner or form of starting point is a good idea. The DAP group has it in its CVS because it is inherited from the APIs that were submitted to it in the beginning, but it's since been abandoned and IMHO for very good reason. I don't think that a cleaned up version will get you anywhere interesting, you need a completely different design.
The problem with the App Launcher API is that there is pretty much no way of making it safe for Web use without making it useless. At the more powerful end of this spectrum you can enumerate installed executables (how that works is in itself an issue, not to mention how you filter it for privacy) and can then run them. I don't think that there is any kind of user interface that will make that functionality safe to run from the Web. At the other end of the spectrum you can have methods like "launch the music player with this". These are typically best served by media types and URI schemes.
Of course you could do something like that if the goal were not to make the APIs in B2G not be Web-safe. But I don't see the value in this, and from reading between the lines I think that the idea is that all of the B2G stack be built with Web APIs. Any monkey with enough time can wrap every lib on the system with js-ctypes but I don't see much value in that. What's hard (and interesting) is to make it work for the Web. That's why DAP dropped App Launcher in favour of an Intents/Introducer approach.
That's not to say that I don't see value in your proposal of having a runtime that can be used on top of an OS rather than requiring a complete replacement. I could well be missing something but I see no reason why the project couldn't have a minimal OS that's just enough to launch the runtime, which in turn could also run elsewhere. But either way there's a bit of code to write before such refinements :)
--
Robin Berjon - http://berjon.com/ - @robinberjon
Andreas Gal
On Jul 25, 2011, at 2:36 PM, Robin Berjon wrote:
> Hi Fabrice,
>
> On Jul 25, 2011, at 19:47 , Fabrice Desré wrote:
>> - An API to list/launch native android apps (based a cleaned up version
>> of http://dev.w3.org/2009/dap/app-launcher/)
If there is a way to launch native android apps from such a system, it would be the same kind of temporary wart that plugins like Flash and Silverlight are for the desktop web platform. If we can't deliver the necessary WebAPIs quickly enough and need Android apps to fill in web platform gaps temporarily, an Android app stop-gap measure might be an acceptable temporary kludge.
In a final system, I don't see much value for this proposal though. The web is in so many ways superior to the locked-in proprietary stores/APIs that it will subsume them pretty quickly as long we make sure the right APIs are in place. This is happening on the desktop today. Your proposal is akin to suggesting that we should urgently add a way to launch Java/native code desktop applications from the desktop browser. It might serve some specific corner cases today, but I doubt it will be relevant in the future.
Andreas
Mike Shaver
> Hi Fabrice,
>
> On Jul 25, 2011, at 19:47 , Fabrice Desré wrote:
>> of http://dev.w3.org/2009/dap/app-launcher/)
Android apps won't likely run on this system once we're done stripping
it down, any more than Linux applications run on Android, so the
launcher isn't likely to be useful even independent of Robin's
well-articulated concerns.
> That's not to say that I don't see value in your proposal of having a runtime that can be used on top of an OS rather than requiring a complete replacement. I could well be missing something but I see no reason why the project couldn't have a minimal OS that's just enough to launch the runtime, which in turn could also run elsewhere.
Whatever we run on top of, we have to bind all these various
capabilities, and many operating systems don't currently expose enough
for us to, f.e., write a dialer app. We'll want to validate against
multiple operating systems in time, but we have to start somewhere,
ideally where we can hack our way around current limitations in the
lower-level stack.
> But either way there's a bit of code to write before such refinements :)
And how! Please help!
Mike
