Booting to the Web

3752 views
Skip to first unread message

Andreas Gal

unread,
Jul 25, 2011, 11:49:17 AM7/25/11
to dev-platform

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

unread,
Jul 25, 2011, 12:39:44 PM7/25/11
to
On 25 juil, 17:49, Andreas Gal <g...@mozilla.com> wrote:

> 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

unread,
Jul 25, 2011, 12:56:28 PM7/25/11
to
Given this, thoughts about, or reactions, or possible work with to
Webian OS? (http://webian.org/ - built on Chromeless)

Ian McKellar

unread,
Jul 25, 2011, 1:19:15 PM7/25/11
to
On Jul 25, 8:49 am, Andreas Gal <g...@mozilla.com> wrote:
> * 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

unread,
Jul 25, 2011, 1:19:45 PM7/25/11
to dev-platform
This is fantastic!

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

unread,
Jul 25, 2011, 1:22:10 PM7/25/11
to Ian Bicking, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 12:56 PM, Ian Bicking <ianbi...@gmail.com> wrote:
> 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

unread,
Jul 25, 2011, 1:23:45 PM7/25/11
to Rob Campbell, dev-platform
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?

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

unread,
Jul 25, 2011, 1:26:46 PM7/25/11
to
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.

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

/be

Mike Shaver

unread,
Jul 25, 2011, 1:27:30 PM7/25/11
to Ian McKellar, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 1:19 PM, Ian McKellar <ian.mc...@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
> 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

unread,
Jul 25, 2011, 1:29:50 PM7/25/11
to
On Jul 25, 5:49 pm, Andreas Gal <g...@mozilla.com> wrote:
> * 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

unread,
Jul 25, 2011, 1:32:38 PM7/25/11
to Mike Shaver, dev-platform

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

unread,
Jul 25, 2011, 1:35:12 PM7/25/11
to

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

unread,
Jul 25, 2011, 1:36:48 PM7/25/11
to Bert Freudenberg

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é

unread,
Jul 25, 2011, 1:47:46 PM7/25/11
to
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/)

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

unread,
Jul 25, 2011, 1:49:13 PM7/25/11
to dev-platform
Awesome news, I recommend integrating BrowserID as well.[1]

[1]https://browserid.org/

Andreas Gal

unread,
Jul 25, 2011, 2:03:01 PM7/25/11
to Fabrice Desré, dev-pl...@lists.mozilla.org

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

unread,
Jul 25, 2011, 1:47:07 PM7/25/11
to
On Jul 25, 10:35 am, Brendan Eich <brendan.e...@gmail.com> wrote:
> 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

unread,
Jul 25, 2011, 2:16:55 PM7/25/11
to
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.

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

Marco


Chris Jones

unread,
Jul 25, 2011, 2:47:45 PM7/25/11
to Marco Zehe
On 07/25/2011 02:16 PM, Marco Zehe wrote:
> 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

unread,
Jul 25, 2011, 2:55:30 PM7/25/11
to
On Jul 25, 10:49 am, Matthew <phillip...@gmail.com> wrote:
> Awesome news, I recommend integrating BrowserID as well.[1]
>
> [1]https://browserid.org/

You bet!

/be

Henri Sivonen

unread,
Jul 25, 2011, 3:14:07 PM7/25/11
to dev-platform
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!

> * 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

unread,
Jul 25, 2011, 3:18:50 PM7/25/11
to Henri Sivonen, dev-platform
On Mon, Jul 25, 2011 at 3:14 PM, Henri Sivonen <hsiv...@iki.fi> wrote:
> 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

unread,
Jul 25, 2011, 3:25:59 PM7/25/11
to
On 7/25/2011 3:14 PM, Henri Sivonen wrote:
> 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

unread,
Jul 25, 2011, 3:30:46 PM7/25/11
to
On Jul 25, 1:23 pm, Mike Shaver <mike.sha...@gmail.com> wrote:

> 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

unread,
Jul 25, 2011, 3:39:12 PM7/25/11
to Stefan Arentz, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 3:30 PM, Stefan Arentz <stefan...@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.

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

Mike

Chris Jones

unread,
Jul 25, 2011, 3:40:01 PM7/25/11
to Stefan Arentz

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

unread,
Jul 25, 2011, 3:56:00 PM7/25/11
to Ian McKellar, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 3:53 PM, Ian McKellar <ian.mc...@rd.io> wrote:

>
> 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
>
> I think that's getting better and better. Nvidia seems (based on my googling) to have drivers available for X for their Tegra chipsets. Tegras are powering most of the nicer Android phones coming out today.

That's great, I should take another look. Thanks!

Mike

ya knygar

unread,
Jul 25, 2011, 5:12:03 PM7/25/11
to g...@mozilla.com, dev-pl...@lists.mozilla.org
Congratulations with a new brave Mozilla project!


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

unread,
Jul 25, 2011, 5:25:03 PM7/25/11
to ya knygar, g...@mozilla.com, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 5:12 PM, ya knygar <kny...@gmail.com> wrote:
> 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

unread,
Jul 25, 2011, 5:36:21 PM7/25/11
to Fabrice Desré, dev-pl...@lists.mozilla.org
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/)

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

unread,
Jul 25, 2011, 5:45:50 PM7/25/11
to Robin Berjon, Fabrice Desré, dev-pl...@lists.mozilla.org

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

unread,
Jul 25, 2011, 5:46:51 PM7/25/11
to Robin Berjon, Fabrice Desré, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 5:36 PM, Robin Berjon <ro...@berjon.com> 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/)

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

unread,
Jul 25, 2011, 6:52:54 PM7/25/11
to
On Jul 25, 11:47 am, Chris Jones <cjo...@mozilla.com> wrote:
> 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

unread,
Jul 25, 2011, 7:51:06 PM7/25/11
to
On Jul 25, 3:39 pm, Mike Shaver <mike.sha...@gmail.com> wrote:

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

unread,
Jul 25, 2011, 8:28:57 PM7/25/11
to
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.

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

unread,
Jul 25, 2011, 9:43:48 PM7/25/11
to Nick Dafo, dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 5:28 PM, Nick Dafo <nickdaf...@gmail.com> wrote:

> Android is already a great mobile O.S. that is open source.
>

Can you provide a link to the Honeycomb source?

- Kyle

Rob A

unread,
Jul 25, 2011, 10:05:55 PM7/25/11
to dev-pl...@lists.mozilla.org
On Mon, Jul 25, 2011 at 5:28 PM, Nick Dafo <nickdaf...@gmail.com> wrote:

> 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

unread,
Jul 25, 2011, 10:07:34 PM7/25/11
to Nick Dafo, dev-pl...@lists.mozilla.org

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

unread,
Jul 25, 2011, 10:16:16 PM7/25/11
to Mike Shaver, dev-platform, Rob Campbell
On Tue, Jul 26, 2011 at 01:23, Mike Shaver <mike....@gmail.com> wrote:

> 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?
>
> 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.
>

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

unread,
Jul 25, 2011, 10:19:39 PM7/25/11
to
I'm really excited about this project. I am a little worried about the
performance aspect though.

Travis Galloway

unread,
Jul 25, 2011, 10:55:00 PM7/25/11
to
Don't forget xPUD. Its a similar concept. But the implementation is a
bit different.

http://www.xpud.org/

Rishi

unread,
Jul 25, 2011, 11:03:02 PM7/25/11
to
On Jul 25, 8:49 pm, Andreas Gal <g...@mozilla.com> wrote:
> 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

exciting....

bob_so...@yahoo.com

unread,
Jul 25, 2011, 11:55:13 PM7/25/11
to
I hope this platform will run XUL apps.
That would be huge IMO. I would definitely
develop for it in that case.

Bob

Tan Yew-wei

unread,
Jul 25, 2011, 11:55:28 PM7/25/11
to dev-platform
Very nice! Is it accurate to say that the point on "New web APIs" encompasses the ability to open UNIX sockets and similar interfaces?

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

unread,
Jul 26, 2011, 12:04:21 AM7/26/11
to bob_so...@yahoo.com, dev-pl...@lists.mozilla.org

XUL should not be considered. Chromeless works just fine.

--
>: ~

Nicholas Nethercote

unread,
Jul 26, 2011, 12:32:30 AM7/26/11
to Kyle Huey, dev-pl...@lists.mozilla.org, Nick Dafo
On Tue, Jul 26, 2011 at 11:43 AM, Kyle Huey <m...@kylehuey.com> wrote:
>
>> Android is already a great mobile O.S. that is open source.
>
> Can you provide a link to the Honeycomb source?

Ooh, I see what you did there.

N

Marco Zehe

unread,
Jul 26, 2011, 3:26:29 AM7/26/11
to
Hi Chris,

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

unread,
Jul 26, 2011, 4:02:18 AM7/26/11
to
Interesting. Might also give the opportunity for memory to be
cooperatively managed by both browser and kernel, rather than the
current unpalatable possibilities of either being summarily nuked or
indiscriminately swapped.

Shmerl

unread,
Jul 26, 2011, 3:29:16 AM7/26/11
to
On Jul 25, 1:26 pm, Brendan Eich <brendan.e...@gmail.com> wrote:
> 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

unread,
Jul 26, 2011, 4:54:31 AM7/26/11
to dev-pl...@lists.mozilla.org
> XUL should not be considered. Chromeless works just fine.
+1 for HTML/CSS/JS styling for everything in B2G.

> 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

unread,
Jul 26, 2011, 5:00:02 AM7/26/11
to
On Jul 25, 5:49 pm, Andreas Gal <g...@mozilla.com> wrote:
> * 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

Natanael L

unread,
Jul 26, 2011, 5:11:23 AM7/26/11
to
Then I suggest that you focus on MeeGo for the sake of technicalities.
MeeGo should be a better enviroment for this than Android.

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


> 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.
>

> Mike

Natanael L

unread,
Jul 26, 2011, 5:22:32 AM7/26/11
to
On Jul 25, 9:18 pm, Mike Shaver <mike.sha...@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 3:14 PM, Henri Sivonen <hsivo...@iki.fi> wrote:
> > 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.
"Locally cached" sounds interesting. How would this work? Is this the
same as the HTML5 offline features? IMHO it seems quite strange to use
that for 100% local apps.
Are you going to provide some kind of local webserver? That would
probably allow for a bit more advanced features, I think.
Then I'm thinking about things like local networking (bluetooth, WiFi,
etc...) and P2P apps. I guess that would move away from HTML+JS, but
you could still go for some PHP/Python based server framework for
local apps and try to standardize that.
It would be interesting to hear your opinions on this.

> > 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

Natanael L

unread,
Jul 26, 2011, 5:29:19 AM7/26/11
to
On Jul 26, 1:51 am, Eric Dorman <edorma...@gmail.com> wrote:
> On Jul 25, 3:39 pm, Mike Shaver <mike.sha...@gmail.com> wrote:
>
> > On Mon, Jul 25, 2011 at 3:30 PM, Stefan  Arentz <stefan.are...@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/
I don't see how source code accessibility and malware are relevant to
each other.
Malware can be found anywhere that code can be uploaded without a
thorough review.

Paul [sabret00the]

unread,
Jul 26, 2011, 5:39:44 AM7/26/11
to dev-platform
Things I'd prefer to see resources devoted to before this:
* Firefox Desktop getting a port of Firefox Mobile chromeless browsing
* Firefox running on internet-enabled televisions
* Firefox Mobile getting the rest of features we're all accustomed to in desktop
* Firefox actually sorting out the MSI installer
* Firefox shipping with GPO support
* Firefox shipping a supported 64bit build on Windows
* Panorama actually supporting OS convention in it's operation
* Globalised App Tabs
* Scalable installations +/- RSS support, Share support, etc.

Paul [sabret00the]

unread,
Jul 26, 2011, 5:39:44 AM7/26/11
to mozilla.de...@googlegroups.com, dev-platform

Ben Francis

unread,
Jul 26, 2011, 5:37:03 AM7/26/11
to Ian Bicking, dev-pl...@lists.mozilla.org
On Monday, July 25, 2011 6:22:10 PM UTC+1, Mike Shaver wrote:
> On Mon, Jul 25, 2011 at 12:56 PM, Ian Bicking <ianbi...@gmail.com> wrote:
> > 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.

Hi there,

I'm the founder of the Webian project.

It sounds like the long term goals of Webian (http://webian.org/about/) and the goals of the B2G project match up almost exactly. I also support your idea of dropping X as a dependency in pursuit of a lighter OS stack.

It's true that the Webian Shell 0.1 prototype runs on desktop OSs, but that's because I chose to use Mozilla Chromeless to rapidly prototype the UI and Chromeless currently doesn't run on mobile OSs. The announcement blog post and video (http://mozillalabs.com/chromeless/2011/05/31/webian-shell-a-full-screen-web-browser-built-on-chromeless/) mentions the desire to add an on-screen keyboard for touch-based devices and I've always intended for Webian to target a range of form factors. I've tried to make design decisions in the UI which don't exclude touch-based devices, even if a desktop device might be an initial target.

I agree with you that mobile is where a lot of the innovation (and media attention) is focussed at the moment, but it does currently seem to have quite a high barrier to entry. If you want to target smartphones for example then unless you partner with hardware manufacturers and mobile carriers to build phones running your operating system out of the box, you're going to be asking users to flash their device. Not a particularly user friendly process and one which could potentially void their warranty.

That's why I've been thinking that for Webian, nettop computers (http://en.wikipedia.org/wiki/Nettop) would be a more realistic initial target. Then perhaps netbooks, smartphones and smart TVs... but that's a long way off.

B2G is an interesting change in direction for Mozilla (http://news.cnet.com/8301-30685_3-10401867-264.html) and I admire your ambition. I'm curious to know what your longer term goals are for the project. Do you see B2G being a homebrew experiment for the foreseeable future, or do you see a consumer-facing OS strategy in the pipeline if the idea proves popular? B2G (like Webian) seems to want to take the best parts of both Android and Chrome OS, which I expect is where Google is ultimately headed too (http://news.cnet.com/8301-30684_3-10402653-265.html).

The Webian Shell prototype has had nearly 90,000 downloads since it was announced so there definitely seems to be some interest in this area. I really hope that B2G takes off and we can collaborate with each other (and others like Chrome OS) to make the open web the software platform of choice.

Ben

--
Ben Francis
http://webian.org

Natanael L

unread,
Jul 26, 2011, 6:00:19 AM7/26/11
to
On Jul 26, 11:37 am, Ben Francis <b...@tola.me.uk> wrote:
> On Monday, July 25, 2011 6:22:10 PM UTC+1, Mike Shaver wrote:
> > On Mon, Jul 25, 2011 at 12:56 PM, Ian Bicking <ianbi...@gmail.com> wrote:
> > > 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.
>
> Hi there,
>
> I'm the founder of the Webian project.
>
> It sounds like the long term goals of Webian (http://webian.org/about/) and the goals of the B2G project match up almost exactly. I also support your idea of dropping X as a dependency in pursuit of a lighter OS stack.
>
> It's true that the Webian Shell 0.1 prototype runs on desktop OSs, but that's because I chose to use Mozilla Chromeless to rapidly prototype the UI and Chromeless currently doesn't run on mobile OSs. The announcement blog post and video (http://mozillalabs.com/chromeless/2011/05/31/webian-shell-a-full-scre...) mentions the desire to add an on-screen keyboard for touch-based devices and I've always intended for Webian to target a range of form factors. I've tried to make design decisions in the UI which don't exclude touch-based devices, even if a desktop device might be an initial target.

>
> I agree with you that mobile is where a lot of the innovation (and media attention) is focussed at the moment, but it does currently seem to have quite a high barrier to entry. If you want to target smartphones for example then unless you partner with hardware manufacturers and mobile carriers to build phones running your operating system out of the box, you're going to be asking users to flash their device. Not a particularly user friendly process and one which could potentially void their warranty.
>
> That's why I've been thinking that for Webian, nettop computers (http://en.wikipedia.org/wiki/Nettop) would be a more realistic initial target. Then perhaps netbooks, smartphones and smart TVs... but that's a long way off.
>
> B2G is an interesting change in direction for Mozilla (http://news.cnet.com/8301-30685_3-10401867-264.html) and I admire your ambition. I'm curious to know what your longer term goals are for the project. Do you see B2G being a homebrew experiment for the foreseeable future, or do you see a consumer-facing OS strategy in the pipeline if the idea proves popular? B2G (like Webian) seems to want to take the best parts of both Android and Chrome OS, which I expect is where Google is ultimately headed too (http://news.cnet.com/8301-30684_3-10402653-265.html).
>
> The Webian Shell prototype has had nearly 90,000 downloads since it was announced so there definitely seems to be some interest in this area. I really hope that B2G takes off and we can collaborate with each other (and others like Chrome OS) to make the open web the software platform of choice.
>
> Ben
>
> --
> Ben Francis http://webian.org

Personally I see the best way to go forward as turning Chromeless into
a base framework with the necessary system API:s, that you then can
run anything on top of.
I have suggested a similiar thing for Ben Francis already for his
Webian project. The idea is essentially that this web OS is a
framework in the background, the interface is an "extension", or an
app running on it. Whatever you see on the screen, it's all extensions/
apps. Each and every one use standard API:s, and can thus be swapped
out for anything else that use those same API:s.
This means that you could easily switch (web) app launcher and
anything else without patching the OS.
If you would like to replace the whole UI for the browser component,
that would be easy to do. If you like to replace the dialer, that's
just as easy. Or the desktop. Or the notification bar/box/icon/drawer/
list/[anything]. Single-click installation (and of course approving
the required permissions for the apps too) and you're done.

What I hope is that this would make prototyping extremely easy and
fast and would let people experiment with more things, much faster. It
would also be extremely flexible and TRULY give the user freedom to do
whatever (s)he wishes to do.

You could think of it as Chromeless+drivers+kernel = a Linux
distribution with drivers, the kernel, base GNU sw and X/Wayland but
no Gnome/Unity/KDE. The Mozilla OS would then be that base plus an
interface and userland apps (like Linux base with Gnome plus office sw
and browsers).

ya knygar

unread,
Jul 26, 2011, 6:41:21 AM7/26/11
to dev-pl...@lists.mozilla.org
> Don't forget xPUD.

yep, last time i saw it there weren't much dev on it,
but, along with Webian and many others Mozilla or not,
mobile or not based initiatives - there are enormous
amount of work in that direction that have been done
already.

for example - http://www.defora.org/
driven by one person for a 6+ years, i think.

Robert Kaiser

unread,
Jul 26, 2011, 7:03:53 AM7/26/11
to
Andreas Gal schrieb:
> 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.

Andreas, I agree with you in the basics there, but let's not even
consider that kludge. The absence of what people want is a quite strong
incentive to fill the gaps. I'm also in communities where providing
temporary kludges or kickstarting things with not really adequate
half-solutions lead to not being able to build up a community doing
things the right way.
The web development community is strong enough that I think the really
important things will be available pretty fast if the web technology for
doing them the right way exists. I also think that making Android apps
part of our experience significantly harms us by binding us to that
Google-controlled stack way too much. If this is to succeed, using a
stable base like Android is good for a start but in the end it needs to
end up with a more free base (when such a base is mature enough, and
it's not at this time).

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

djevrek

unread,
Jul 26, 2011, 7:09:15 AM7/26/11
to dev-platform
I would like:
* Google to enable + button for users posts
so i can like your comment.

Henri Sivonen

unread,
Jul 26, 2011, 7:11:00 AM7/26/11
to dev-pl...@lists.mozilla.org
On Tue, 2011-07-26 at 02:22 -0700, Natanael L wrote:
> "Locally cached" sounds interesting. How would this work? Is this the
> same as the HTML5 offline features? IMHO it seems quite strange to use
> that for 100% local apps.

Well, are any apps 100% local in the sense that you wouldn't want to
pull updates from the network? If you do want updates, W3C Widgets (or
similar) plus widget updating becomes a second system to support
alongside the HTML5 app cache.

OTOH, "local" apps (all app logic in client-side JS) bundled with the
system could ship as prefilled HTML5 app caches and could thereafter
update themselves from whatever server their URLs point to--the same way
as non-bundled HTML5 appcache-enabled Web apps would update their cached
parts.

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

d.hit...@tesco.net

unread,
Jul 26, 2011, 7:10:15 AM7/26/11