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
azakai
> On 07/25/2011 02:16 PM, Marco Zehe wrote:
> > 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.
I definitely agree that sort of thing can be done on web pages. We can
also compile existing C/C++ codecs into JS for this (perhaps even the
relevant Android framework itself).
In general I think that making it easier for people to compile stuff
into JS, as opposed to adding new native code into the browser, is the
preferable approach, at least for things like this (codecs/logic/non-
hardware accessing stuff).
- azakai
Eric Dorman
I think this is a great idea for the web, but security has to be one
of the center pieces around this OS.
In my opinion, Android is suffering from attacks because some of their
source code is very sensitive to the platform and is constantly being
the victim of malware attacks.
Nick Dafo
this.
Android is already a great mobile O.S. that is open source.
It may run native apps but i see no problem with that. Plus, it has a
great browser that is always getting better with each release so it
supports the HTML5 web apps that mozilla (and also google) likes.
If Mozilla wants to support open source and the web in mobile devices
you should better work as much as possible on the Android version of
Firefox instead of trying to create a whole new O.S.
There is no need for another O.S. if you can build a great Firefox app
for an existing open source O.S. that is already out on the market and
growing faster than the closed systems like apple's and microsoft's.
You may think that i may be saying this because i love Android but
there is much logic and reason in my words.
Kyle Huey
> Android is already a great mobile O.S. that is open source.
>
Can you provide a link to the Honeycomb source?
- Kyle
Rob A
> It may run native apps but i see no problem with that. Plus, it has a
> great browser that is always getting better with each release so it
> supports the HTML5 web apps that mozilla (and also google) likes.
>
It doesn't have a great browser at all; it is at best mediocre. No
web-worker support (was there in 2.1, disappeared in 2.2+), poor support for
CSS transforms. No SVG support until honeycomb came out. No WebGL. No inline
html5 video. Poor performance overall (network, graphics, and touch) and
it's full of quirks across manufacturers (ex: my phone doesn't show
scrollbars). Also, I can't upgrade it. It may get better in each release but
I am at the mercy of the carriers/oems for upgrading. I am essentially
locked into one version of the browser, maybe two if I'm lucky (though
little changed in Gingerbread).
-Rob
Andreas Gal
On Jul 25, 2011, at 5:28 PM, Nick Dafo wrote:
> As a huge Android supporter i dont see why you find the need to do
> this.
>
> Android is already a great mobile O.S. that is open source.
Android is not open source in the sense of "open technology". Android APIs are proprietary Google sauce, not broadly accepted and adopted open web standards. At some point Android used to be at least "available source" where Google would publish secretly/internally developed source code/technology after the fact as products ship, but even those times seem to be over now. I would love to boot my custom Android build on my Galaxy Tab 10", but no luck, Google refuses to release the source.
We want to do Boot to Gecko the way we think open source should be done. In the open, from day 1, for everyone to see and participate.
Andreas
Cedric Vivier
> On Mon, Jul 25, 2011 at 1:19 PM, Rob Campbell <rcam...@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?
>
> pulling in things like X, which we don't want to do.
>
Since this is about the future, did you consider Wayland?
Afaik it has been designed for use on embedded devices as well.
Awesome project.
sung
performance aspect though.
Travis Galloway
bit different.
Rishi
> 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;
>
> 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
exciting....
bob_so...@yahoo.com
That would be huge IMO. I would definitely
develop for it in that case.
Bob
Tan Yew-wei
Or to take it a step further, perhaps with this project, is it possible to build a new abstraction for networking? (thus avoiding the hairiness of sockets -> a JS-callable version of zeromq perhaps [http://www.zeromq.org/])
Wan Li
XUL should not be considered. Chromeless works just fine.
--
>: ~
Nicholas Nethercote
>
>> Android is already a great mobile O.S. that is open source.
>
Ooh, I see what you did there.
N
Marco Zehe
Am 25.07.2011 20:47, schrieb Chris Jones:
> 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.
Yes, I was there when Dave Humphrey demoed this at Whistler 2010. The
quality of the synth was...well...close to the 1980s. Seeing that it was
written in pure JS, however, was fantastic! But I agree it's something
worth looking at, and we need to be aware of multilingual support.
> 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.
We just recently made a decision on how to move forward with
accessibility for Firefox Mobile on Android, and this work will
definitely benefit the B2G project, and we can learn a lot this way.
Cheers,
Marco
jse...@acm.org
cooperatively managed by both browser and kernel, rather than the
current unpalatable possibilities of either being summarily nuked or
indiscriminately swapped.
Shmerl
> 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.
>
> > 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.
>
So why promoting their moves? Promote Wayland. Meego should be a
better candidate for that.
Hillel.
ya knygar
> 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.
of-course but given the closed source of latest Android,
given that in opinion of many from FLOSS community -
world would really benefit from GNU/Linux portable OS's (that, by the way,
are developed and tested seriously by the community and would be used
widely, sooner or later,
SHR just another working example - could be installed on iPhones, and,
most of the ARM's are just untested with it,
not that there are many compatibility issues).
If Mozilla dev's would support the freedom OS's in one or other way -
that would likely to rise the Question of
vendor locked-mobiles and the possibility of mobiles computers to
became a PC like machines in which user
could easily install OS of the choice. Work on B2G would help it
anyway, but supporting particularly a freedom OS's
"back-end" could
bring a much larger attention and what is more valuable - support of
community, and, maybe,
some amazing collaborative affords.
Supporting Android is rising up the questions that lead in a kind of
different direction where -
why do we need to re-flash OS if we could run the OS into OS like
Chromeless OS's for example.
Again - it's just my observation.
Porting to GNU/Linux would be done anyway, i think, but this is the
point where, obviously, both Mozilla and GNU/FSF/etc.
community would largely benefit from collaboration. And working with
Google - given what i know about it's work with community,
and helping the forks, in particular,
is a controversial decision.
Marcos
> * New web APIs: build prototype APIs for exposing device and OS capabilities to content (Telephony, SMS, Camera, USB, Bluetooth, NFC, etc.)
The W3C is already working on a bunch of these (Device API Working
Group) [1]. Has Moz evaluated those or considered joining that working
group?
> * Applications: choose and port or build apps to prove out and prioritize the power of the system.
It would be good if packaged applications made use of an open
standardized format... like W3C Widgets [2] [3]... instead of adding
another proprietary layer :)
[1] http://www.w3.org/2009/dap/
[2] http://www.w3.org/TR/widgets/
[3] http://www.w3.org/2008/webapps/wiki/WidgetSpecs