Booting to the Web

Showing 1-226 of 226 messages
Booting to the Web Andreas Gal 7/25/11 8:49 AM

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

Re: Booting to the Web Tristan Nitot - Mozilla 7/25/11 9:39 AM
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

Re: Booting to the Web Ian Bicking 7/25/11 9:56 AM
Given this, thoughts about, or reactions, or possible work with to
Webian OS? (http://webian.org/ - built on Chromeless)
Re: Booting to the Web Ian McKellar 7/25/11 10:19 AM
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

Re: Booting to the Web Rob Campbell 7/25/11 10:19 AM
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

Re: Booting to the Web Mike Shaver 7/25/11 10:22 AM
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

Re: Booting to the Web Mike Shaver 7/25/11 10:23 AM
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

Re: Booting to the Web Brendan Eich 7/25/11 10:26 AM
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

Re: Booting to the Web Mike Shaver 7/25/11 10:27 AM
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

Re: Booting to the Web Bert Freudenberg 7/25/11 10:29 AM
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 -

Re: Booting to the Web Mike Hommey 7/25/11 10:32 AM

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

Re: Booting to the Web Brendan Eich 7/25/11 10:35 AM

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

Re: Booting to the Web Chris Jones 7/25/11 10:36 AM

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

Re: Booting to the Web Fabrice Desré 7/25/11 10:47 AM
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

Re: Booting to the Web Matthew Phillips 7/25/11 10:49 AM
Awesome news, I recommend integrating BrowserID as well.[1]

[1]https://browserid.org/

Re: Booting to the Web Andreas Gal 7/25/11 11:03 AM

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

Re: Booting to the Web Brendan Eich 7/25/11 10:47 AM
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

Re: Booting to the Web Marco Zehe 7/25/11 11:16 AM
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


Re: Booting to the Web Chris Jones 7/25/11 11:47 AM
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

Re: Booting to the Web Brendan Eich 7/25/11 11:55 AM
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

Re: Booting to the Web Henri Sivonen 7/25/11 12:14 PM
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/

Re: Booting to the Web Mike Shaver 7/25/11 12:18 PM
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

Re: Booting to the Web Randell Jesup 7/25/11 12:25 PM
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

Re: Booting to the Web Stefan Arentz 7/25/11 12:30 PM
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.

Re: Booting to the Web Mike Shaver 7/25/11 12:39 PM
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

Re: Booting to the Web Chris Jones 7/25/11 12:40 PM

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

Re: Booting to the Web Mike Shaver 7/25/11 12:56 PM
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

Re: Booting to the Web ya knygar 7/25/11 2:12 PM
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.

Re: Booting to the Web Mike Shaver 7/25/11 2:25 PM
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

Re: Booting to the Web Robin Berjon 7/25/11 2:36 PM
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

Re: Booting to the Web Andreas Gal 7/25/11 2:45 PM

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

Re: Booting to the Web Mike Shaver 7/25/11 2:46 PM
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

Re: Booting to the Web azakai 7/25/11 3:52 PM
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

Re: Booting to the Web Eric Dorman 7/25/11 4:51 PM
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/
> > 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

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.

Re: Booting to the Web Nick Dafo 7/25/11 5:28 PM
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.

Re: Booting to the Web Kyle Huey 7/25/11 6:43 PM
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

Re: Booting to the Web Rob A 7/25/11 7:05 PM
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

Re: Booting to the Web Andreas Gal 7/25/11 7:07 PM

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

Re: Booting to the Web Cedric Vivier 7/25/11 7:16 PM
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.

Re: Booting to the Web sung 7/25/11 7:19 PM
I'm really excited about this project. I am a little worried about the
performance aspect though.

Re: Booting to the Web Travis Galloway 7/25/11 7:55 PM
Don't forget xPUD. Its a similar concept. But the implementation is a
bit different.

http://www.xpud.org/

Re: Booting to the Web Rishi 7/25/11 8:03 PM
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....

Re: Booting to the Web bob_so...@yahoo.com 7/25/11 8:55 PM
I hope this platform will run XUL apps.
That would be huge IMO.  I would definitely
develop for it in that case.

Bob

Re: Booting to the Web Tan Yew-wei 7/25/11 8:55 PM
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/])

Re: Booting to the Web Felix 7/25/11 9:04 PM

XUL should not be considered. Chromeless works just fine.

--
>: ~

Re: Booting to the Web Nicholas Nethercote 7/25/11 9:32 PM
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

Re: Booting to the Web Marco Zehe 7/26/11 12:26 AM
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

Re: Booting to the Web jse...@acm.org 7/26/11 1:02 AM
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.
Re: Booting to the Web Shmerl 7/26/11 12:29 AM
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.

Re: Booting to the Web ya knygar 7/26/11 1:54 AM
> 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.

Re: Booting to the Web Marcos 7/26/11 2:00 AM
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

Re: Booting to the Web Natanael L 7/26/11 2:11 AM
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

Re: Booting to the Web Natanael L 7/26/11 2:22 AM
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

Re: Booting to the Web Natanael L 7/26/11 2:29 AM
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.
Re: Booting to the Web Paul [sabret00the] 7/26/11 2:39 AM
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.
Re: Booting to the Web Paul [sabret00the] 7/26/11 2:39 AM
Re: Booting to the Web Ben Francis 7/26/11 2:37 AM
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

Re: Booting to the Web Natanael L 7/26/11 3:00 AM
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).

Re: Booting to the Web ya knygar 7/26/11 3:41 AM
> 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.

Re: Booting to the Web Robert Kaiser 7/26/11 4:03 AM
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! :)

Re: Booting to the Web djevrek 7/26/11 4:09 AM
I would like:
* Google to enable + button for users posts
so i can like your comment.
Re: Booting to the Web Henri Sivonen 7/26/11 4:11 AM
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/

Re: Booting to the Web d.hit...@tesco.net 7/26/11 4:10 AM
On Jul 26, 2:43 am, Kyle Huey <m...@kylehuey.com> wrote:

> On Mon, Jul 25, 2011 at 5:28 PM, Nick Dafo <nickdafomob...@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

Why a 'great mobile OS'

Its not a deliberate start to an argument, I honestly don't have a
massive insight into the workings of Android. I do know that Symbian -
that much maligned OS has a very good kernel, several features to
prevent memory leaks, keep battery consumption low, prevent memory
tramples and so forth. I appreciate the S60 UI had become a somewhat
inefficient bloated sluggish wreck but Nokia had been striving to make
some improvements. From my perspective - given the huge installed base
of Symbian devices, the low BOM, the flexibility built in, that
building a decent UI on top of the Symbian Kernel would have been a
good option.

I would be interested in this project, I've worked on email, web
browsers and mobile devices for a very long time (way back with pagers
and then through the very early days of GSM).

The decision (as I have read it) is to take Android and rewrite a lot
of it... if Android is that good a starting point surely rewriting is
not a good idea? Symbian would make a good, established, tested and
working start point.
It certainly is possible to create an entire phone UI based on a web
type system - this was behind some of the original WAP 1.0 proposals,
Mobile Explorer also worked along these lines (with all the web
settings, email client, dynamic home pages etc.) being web pages. I
know a collegue that had some interesting ideas around further
enhancements to web layouts that would enable a good deal of
flexibility about how to respond to phones with different shape
screens, different button locations etc. (Mobile Explorer coped with
different screen sizes and featured interesting ideas like not having
any left/right scroll on any webpage, but relaying to fit a scroll
up.down only model as supported by the old Sony Z5 job dial)


Re: Booting to the Web d.hit...@tesco.net 7/26/11 4:17 AM

I think speech is good, but generally the processing required to
achieve it is rather on the high side. It might be an exciting
additional project, but perhaps its a sideline?

Re: Booting to the Web Robert Kaiser 7/26/11 4:21 AM
ya knygar schrieb:
> 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.

NVidia is still the proprietary openness-hostile thing it used to be,
and Tegra doesn't change any bit of that. Mozilla is not interested in
building hardware, though, and a good bunch of modern, capable devices
right now are Tegras, Mozilla also happens to own a number of those to
run tests for our Android version of Firefox, and we need some point to
start this experiment on, so that's a natural choice. Mozilla also
doesn't want to go into developing drivers, we want to improve the web
stack, so we're building on what's there but make it as portable as
possible so it can run on a number of other hardware if people are
willing to try.

> Could you, please, tell - when do you plan to evaluate these
> non-Android variants?

 From all I understand, what's being developed here won't be dependent
on Android at all, Mozilla will just use it as the base to run this
experiment for now, as it is there and stable enough to work on. Mozilla
is not interested in developing low-level OS software, drivers, or
anything like that, but just the layer that connects that layer with web
applications, i.e. what was a "browser" in the past and is a "web
application runtime" nowadays - just that we want to give web apps the
capabilities to use a lot of the underlying device.

Android on Tegra is a good starting point now (just as Maemo on N810 was
when we started doing a mobile browser) as we need something ready to
use and stable enough that we can concentrate on the web application
runtime layer we know best. It by no way should be the only
hardware/software combination this runs on.

I'm personally convinced that some alternative to Android will come up
in the next few years (MeeGo and WebOS are in good positions there,
having some power and deployment behind them, even if not in the
conventional markets - e.g. most people don't even know about the
millions of cars that will be delivered with MeeGo installed) and I'd be
very happy if this project would run on a really open stack instead of
the proprietary (source thrown over the wall if you're lucky is nothing
like open), tightly-controlled Android. But we're not at a point where
we either know which more open stack will succeed nor in a position we
can work on one to get there, working on the web application runtime is
a large enough project as it is.

(And note that I'm not part of this project even though I work for
Mozilla, I just got to know about it because someone from the local
media called me and wanted a statement about this from me.)

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! :)

Re: Booting to the Web d.hit...@tesco.net 7/26/11 4:15 AM
On Jul 26, 3:19 am, sung <4phle...@gmail.com> wrote:
> I'm really excited about this project. I am a little worried about the
> performance aspect though.

Why? As I said elsewhere, I don't know about the Android stuff, I do
know the basic Symbian Kernel is good (I appreciate many applications
and S60 is not wonderful, but the discussion already is around
replacing a lot of Android, so I wonder if Symbian wouldn't be a
better start point - it was designed for battery power, low memory,
long life embeded devices in the first instance so has a good deal of
well thought through features for this - despite the cruft that grown
on top over the years).

Re: Booting to the Web Robert Kaiser 7/26/11 4:24 AM
Wan Li schrieb:

IMHO, HTML currently is incapable of doing great UI, but XUL can do that
right now. But then, I think exactly that's another thing we need to
change with this project and the new standards we need to work on to get
all this working! :)

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! :)

Re: Booting to the Web d.hit...@tesco.net 7/26/11 4:25 AM

I would think the most interesting version would be to do the WHOLE UI
in browser technology, with the browser dealing with caches,
tokenising and generally managing its memory. The activities such as
Bluetooth etc. could probably be placed at a layer around the kernel
and be permanently in place and allocating memory only when used.
Symbian kernel has some reasonable memory handling functions.
As I said elsewhere the original WAP 1.0 spec had features to enable
the whole UI to be done in browser technology, indeed Mobile Explorer
used a modified HTML system (templates with tokens for accessing some
data) to provide for the settings pages, menus, email client,
autoupdating home pages and a number of similar things. In fact, you
could send WAP push messages to the home page to keep it up to date,
change the home page by pushing (or pulling) over the air. This
approach might leave us open to having a system that is equally at
home using 'cloud applications' or downloading them for use in railway
tunnels and other unconnected environments....

Re: Booting to the Web Robert Kaiser 7/26/11 4:28 AM
Natanael L schrieb:

> Then I suggest that you focus on MeeGo for the sake of technicalities.
> MeeGo should be a better enviroment for this than Android.

If MeeGo succeeds (and sure as hell I hope that it will), then it once
will be a better environment, that's true. Right now, it's not nearly
mature enough to build our web application runtime on top of it and not
care about the low-level OS underneath. Android is mature enough for
that, so it's the obvious choice for a start. Mozilla will not hook into
a lot of Android-specific things, though, and make this highly portable
therefore. I hope, just like you probably do, that it can run on a way
more open stack in the future - and if people from the MeeGo community
are interested in getting this to run there once we have something to
show, I'm very sure that our people working on this will cheer and help
to get it done.

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! :)

Re: Booting to the Web David Rusling 7/26/11 4:33 AM
Anything that Linaro can help with?

Dave

On Jul 25, 4: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

Re: Booting to the Web Robert Kaiser 7/26/11 4:37 AM
d.hit...@tesco.net schrieb:

> The decision (as I have read it) is to take Android and rewrite a lot
> of it...

Man, I hope not. The UI layer, yes, but the lower layers are hopefully
nothing Mozilla will even consider to rewrite or even touch, but just to
integrate with. It's not just the kernel, there's a whole lot of
userspace stuff to glue high-level UI to low-level kernel etc. workings.
I just hope whatever Android has there (I have so far refused to touch
that proprietary system) is not too far apart from more generic (and
really open) Linux stacks so we can easily build upon more open stack in
the future when they become more mature.

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! :)

Re: Booting to the Web ya knygar 7/26/11 5:13 AM
> P2P apps.
it's webrtc.org by that - could be done like "real" web apps with
indexed db, i think.

what i propose is:

decouple the Chromeless like(by html5 stack styling idea and reuse
Prism/WebRunner ideas, by-the-way) Mobile Gecko part as a installable
browser for web Apps,
by Web Apps.
To run on existing and partially open mobile platforms. That are  able
to handle reworked the "client" side like SpiderMonkey compilation for
web browsing, like XULRunner with HTML rather than XUL for dynamic
styling given from standardized Web Apps.


Let it be alpha-omega if any official Mozilla build, but people will
adopt and test it, fork and invent for it..


..with existing API's on platform(s) but, anyway, someone would do it

So - decouple it from back-end OS part, even if device API's that
could be used would differ in that OS
from Mozilla OS, that what i propose, for the overall B2G adoption
part by part.


>Things I'd prefer to see resources devoted to before this:
>* Firefox Desktop getting a port of Firefox Mobile chromeless browsing
+1

>* Firefox running on internet-enabled televisions
+1 BTW - it's another +1 for non-Android backend
https://wiki.mozilla.org/Mobile/Embedding

>* Firefox Mobile getting the rest of features we're all accustomed to in desktop
i propose to continue to work on Mobile Firefox as the stable,
"normal" build for mobiles,
there would be these Moz Open Web Apps places like
https://wiki.mozilla.org/Mobile/Projects/WebApp_Support
and other work that could potentially - not suit to "normal" Firefox Mobile.
Maybe, further from what i proposed above - Mobile FF could evolve
into a part of Moz OS

>* Firefox actually sorting out the MSI installer
:)

>* Firefox shipping with GPO support
what is GPO?

>* Firefox shipping a supported 64bit build on Windows
+1

>* Panorama actually supporting OS convention in it's operation
...
>* Globalised App Tabs
like a part of OS? +1 it's a kind of Chromeless OS's work

>* Scalable installations +/- RSS support, Share support, etc.
that would be wonderful.

-

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

+1! Moz platform powered UI for OS - is the best desicion i could see,
they are doing CSS/JS in these GUI's anyway, could be very, very, useful
given that Win8 could also evolve into kind of Web OS.
Imagine the community driven OS that would compete with Win, even
on gaming and recreation field..

>The Mozilla OS would then be that base plus an
>interface and userland apps (like Linux base with Gnome plus office sw
>and browsers).

do you mean - userland for like LibreOffice on Moz OS? ;
Chromeless like GUI and base for running native web apps,
along with recompiled/ported GTK/Qt/ other potable apps like
on GNU/Linux distributive's now?

PS: excuse me for double-post if for someone.. i'v mailed to this list
into BCC accidentally,
 waited for moderation for an hour
and still - haven't seen my message in google group.. don't repeat my mistake:)

Re: Booting to the Web SRAO 7/26/11 5:10 AM
This is a good idea to start a project to displace the current popular embedded OS. A good start for the project is similar to Chrome OS for example - boot using uboot, launch linux kernel and load device drivers for the device, linux launches the start-up shell firefox or launches firefox service API (Open Mobile API) with custom shell for operators.

From my previous experience working with embedded space, I see the following problems

1) Device Drivers - most of the silicon vendors want revenue for there efforts not only to manufacture the device, also for device drivers. Some give it free as open source - not all. If we look at Linux desktop OS, it is still difficult to get some drivers for say SDX cards / graphic drivers. With Google behind Android and working closely with Manufacturers to get the drivers to the world for innovative hardware like 3D displays with recent HTC and LG phones. Microsoft has industry partners. Apple gets everything in-house. Nokia, finally in process of giving up Symbian. For Mozilla this would be a difficult challenge to get the drivers for all kinds of devices in the market. Easiest to target for the project would be a tablet with standard WIFI.

2) Telephony/Wireless, Codec Patents – this is highly explosive area, and Android and as such Linux itself is being targeting from time to time.

3)  Industry Support – The project needs to start with a reference hardware design. There are number of hardware designs available such as Beagleboard from hobbyist to OMAP ZOOM platforms for commercial innovative devices. There are many more. As the project is embedded in nature, the first reference design needs to be cheaper such that project participants can buy at cheaper price for producing demo software. Initially an emulator such as QEMU is good. Personally, hardware availability is the best for developers for such projects.  Industry support is a must to get the hardware device drivers for new devices, otherwise the fate would be similar to linux running on old devices.

4) App Market - The mobile OS market is highly fragmented like the 1980’s with different desktop OS’s. For mobile – Android, Ubuntu  MID(dead now), Nokia Symbian, Microsoft Windows Phone, Apple iOS. Each OS has its own App market and none of them are interoperable. Applications make the device more useful. Should be easy as Apple iOS SDK, Secure as in Symbian Applications, Cross-platform as in Android for multiple devices, intuitive as Windows Phone UI. The challenge is to define best possible API’s for exposing device functionality across multiple vendor handsets.

My suggestion rather then starting a new Mobile OS – pick one that is already available open source like Android, and join hands to make it stable or fork Android to support Gecko shell.

This is good start in one direction – keep it going, just sharing my insights from the Embedded world.

Re: Booting to the Web Nayeem 7/26/11 5:45 AM

I appreciate the attempt by an established player like Mozilla to
venture into the territory of the mobile OS.
The point I want to raise here is: will there be a support for the
cloud based services and/or whether Mozilla itself is going to provide
some kind of cloud. Something like what Apple is doing with their
mobile devices. I read at a tech website that this OS will be
targeting the Chrome OS of Google, which means a cloud like
infrastructure working behind the browser like interface of the users'
devices.

Re: Booting to the Web ya knygar 7/26/11 6:07 AM
> IMHO, HTML currently is incapable of doing great UI, but XUL can do that
> right now. But then, I think exactly that's another thing we need to
> change with this project and the new standards we need to work on to get
> all this working! :)

exactly as i think :)

this project could became the catalyst software point,
where the latest standards, innovations and ideas are
being developed to implementation point, tested and becoming reality :

something what Firefox couldn't afford being in continuous mass use,
maybe - like ideology successor of previous Aurora conceptions.
(before Aurora became a name of the dev channel for Firefox)

>4) App Market - The mobile OS market is highly fragmented like the 1980’s with different desktop OS’s. For mobile – Android, Ubuntu  MID(dead now), >Nokia Symbian, Microsoft Windows Phone, Apple iOS. Each OS has its own App market and none of them are interoperable. Applications make the >device more useful. Should be easy as Apple iOS SDK, Secure as in Symbian Applications, Cross-platform as in Android for multiple devices, intuitive as ?


>Windows Phone UI. The challenge is to define best possible API’s for exposing device functionality across multiple vendor handsets.

i believe the point of Open Web Apps initiative is to make the new
world market of open web apps that would incorporate all the above
goods - with help of web OS's that - if browsers would follow W3C
ideas - these browser will became finally. I'm glad that with this
initiative -
it would be rather sooner than later.

There are much more for a mobiles in use  -- WebOS, RIM, Bada, some
custom Chinese products..
The Problem -  most of these "mobile OS's" aren't even close to
desktop one's because of
every major corporation have a hand to grab the market into closed
structure.. in result -
no interoperability etc.

And only chance for Future to not became a Closed Proprietary
(given the consumer ratio of mobiles/pc's market) with a surveillance
in your pocket or bag - is to make the open apps on web platform.

If the problem is in JavaScript/HTML/CSS knowledge for *any* developer,
well - there was all this time to realize the politics of W3C
and browser developers and to propose something better.

>2) Telephony/Wireless, Codec Patents – this is highly explosive area, and Android and as such Linux itself is being targeting from time to time.


 i have posted to FreedomBox and would participate in it's or other
group of developers that would make a Freedom mobile OS,
with ideas of freedom box or kind of.

> 1) Device Drivers - most of the silicon vendors want revenue for there efforts not only to manufacture the device, also for device drivers. Some give it free as open source - not all. If we look at Linux desktop OS, it is still difficult to get some drivers for say SDX cards / graphic drivers. With Google behind Android and working closely with Manufacturers to get the drivers to the world for innovative hardware like 3D displays with recent HTC and LG phones. Microsoft has industry partners. Apple gets everything in-house. Nokia, finally in process of giving up Symbian. For Mozilla this would be a difficult challenge to get the drivers for all kinds of devices in the market. Easiest to target for the project would be a tablet with standard WIFI.

if we'll ignore all the GNU-like mobile operation system initiatives
we will lose
more than drivers. I am sure - the situation on today's mobile market or
certain advantages of reusing Google products - shouldn't
dictate Mozilla - how to make the world a better place.

> 3)  Industry Support – The project needs to start with a reference hardware design. There are number of hardware designs available such as Beagleboard from hobbyist to OMAP ZOOM platforms for commercial innovative devices. There are many more. As the project is embedded in nature, the first reference design needs to be cheaper such that project participants can buy at cheaper price for producing demo software. Initially an emulator such as QEMU is good. Personally, hardware availability is the best for developers for such projects.  Industry support is a must to get the hardware device drivers for new devices, otherwise the fate would be similar to linux running on old devices.


My, personal, opinion - Intel would be strong enough on mobile market
with open source
and NVidia would be with what is cool - they have an option for mobile
Ubuntu and they will
have for any mobile with Mozilla if it will be Mozilla's initiative.
Qualcomm and other ARM would
be just a producers of cpu's.. i hope..

My strong believe that - we all for good of all - need to make the
mobile market more
like a PC not like the consoles approach it has now. We shouldn't
leave the desicions
of what will operate in our pockets or homes to broadband, cell, or
other vendors.
I could bring the many terrible examples of such a power in corporative hands,
i hope you know it, already.

> The point I want to raise here is: will there be a support for the
> cloud based services and/or whether Mozilla itself is going to provide
> some kind of cloud

FreedomBox is working on it, if not - there are enough of other initiatives,
like Unhosted.org, ownCloud.org etc.etc.

I'm dedicated developer of Augmented Reality systems, knowing the
today's AR market and
corporations work (almost every you can name like a Big) in it -- what i need
to conclude here

-  Mobile systems with all the camera's, GPS's and other tech inside -
aren't like the desktop, they  the vaguest points of "" interest
and the first platform to defeat from proprietary corporations that i
could imagine.

Given that certain mobile vendors their partners etc. etc. could
control by gathering
and even intrusion - the tech in many mobiles, even in that - you may use now.
Given that Android haven't made the reputation of very open OS
(believe me i know what i'm talking about, there are facts "from the
fields", not only AR)  and
every bit of that partial closeness is control in certain hands -- i hope
Mozilla will continue to do the best and un-compromised  job in the area
of Open and Freedom systems.

Re: Booting to the Web ya knygar 7/26/11 6:16 AM
> established player like Mozilla to
> venture into the territory of the mobile OS.

i hope that Mozilla would be more like community
and part of wider FLOSS community,
not a player in this area =)

PS: i'v proposed in some recent survey to make at least the "cloud" Mozilla
mail for these BrowserID's, i think - it's the best
we could hope to see hosted in an open corporation
with a limited, comparing to proprietary  resources.
The best of the best, for me, is to hope that - if such
a hosting would be provided it would be based on internal
Mozilla's facilities not on third-party cloud hosting l)

Re: Booting to the Web Robin Berjon 7/26/11 6:17 AM
On Jul 26, 2011, at 13:11 , Henri Sivonen wrote:
> 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?

I can't think of any app for which I would not want a simple and straightforward update path, but I can think of several for which I absolutely do not want to upgrade to the latest version, want to upgrade but only after I've finished the current critical project which would not tolerate data loss or even new bugs, and it has often happened that I've wanted to downgrade back from an upgrade.

While I definitely find the App Cache approach to be rather elegant, I think that it tends to sweep quite a few things under the rug. This is one aspect for which I'd like to forget which standard may or may not be better, or even the fact that we have a standard at all and figure out what we'd like the solution to look like. Then we pick whichever standard's closest (if any) and bang it into shape.

One design consideration that I think should be important here is that the Web is not the Cloud. I want to be able to run an application from a third party without having to rely on them hosting a web site in perpetuity, trusting them not to do anything stupid with upgrades, or coming anywhere near my data — I want the latter on a Sync server which I trust. This is not a browser; we don't have to shoehorn everything into a tab from day one!

In my fantasy world we could get the BOBW by using git as the application distribution format (naturally with a UI that doesn't scare people away). It certainly has properties that are more interesting than either AppCache or Widgets. And it shouldn't be excessively painful to implement either. Using its HTTP protocol, we might just be able to transparently tie-in web sites as well.

> If you do want updates, W3C Widgets (or
> similar) plus widget updating becomes a second system to support
> alongside the HTML5 app cache.

If there are use cases for both, then the differences aren't that huge. A hackish converter from one to the other is not overwhelmingly hard to write: http://berjon.com/blog/2009/06/appcache-to-widget-converter.html. But again, I'd like existing standards to not be the beginning of this conversation.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Booting to the Web Marco Zehe 7/26/11 6:23 AM
Am 26.07.2011 13:17, schrieb d.hit...@tesco.net:

> I think speech is good, but generally the processing required to
> achieve it is rather on the high side. It might be an exciting
> additional project, but perhaps its a sideline?

Accessibility is a core part of Mozilla's mission. A few months ago we
even formed a dedicated team for this within the engineering department.
So no, this is not a sideline.

Marco

Re: Booting to the Web Natanael L 7/26/11 6:24 AM
Replies inline:

On Jul 26, 2:13 pm, ya knygar <kny...@gmail.com> wrote:
> > P2P apps.
>
> it's webrtc.org by that - could be done like "real" web apps with
> indexed db, i think.

Yes, WebRTC is perfect for (most of) this. Real-time network
communication is essential.

> what i propose is:
>
> decouple the Chromeless like(by html5 stack styling idea and reuse
> Prism/WebRunner ideas, by-the-way) Mobile Gecko part as a installable
> browser for web Apps,
> by Web Apps.

This mostly the same as what I said. Just phrased differently.

[...]

> >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.
>
> +1! Moz platform powered UI for OS - is the best desicion i could see,
> they are doing CSS/JS in these GUI's anyway, could be very, very, useful
> given that Win8 could also evolve into kind of Web OS.
> Imagine the community driven OS that would compete with Win, even
> on gaming and recreation field..

Indeed, we could have very exiting UI:s! Mozilla OS should REALLY be
split up in modules, the platform and the interface should be
separated. Integration between the two should be done with API:s that
ANY app can use.

> >The Mozilla OS would then be that base plus an
> >interface and userland apps (like Linux base with Gnome plus office sw
> >and browsers).
>
> do you mean - userland for like LibreOffice on Moz OS? ;
> Chromeless like GUI and base for running native web apps,
> along with recompiled/ported GTK/Qt/ other potable apps like
> on GNU/Linux distributive's now?

What I mean is this:
Ubuntu and Mozilla OS both use the Linux kernel and drivers for their
hardware.
Then things differ: Where Ubuntu use X (soon Wayland?) and GNU
software, there will be Chromeless on Mozilla OS.
Where Ubuntu use Gnome, there will be the Mozilla OS interface, built
in HTML+JS.
Where Ubuntu has applications like OpenOffice, Mozilla OS will run
HTML5 web apps, both web based like Google Docs and local ones (also
in HTML5; using HTML5 offline features) built for this purpose.
Porting software (like recompiling Qt apps) is a completely different
thing. That should be done too some day, but it's not a priority.
Mozilla OS should run HTML5 apps.

Re: Booting to the Web tuseroni 7/26/11 6:26 AM
http://bellard.org/jslinux/ thought i would point to this. its a pc
emulator written in javascript and running a linux kernel. this seems
like a good starting point. you have a complete OS you just need to
get a way to communicate more with the hardware and maintain
persistence. if you can get the browser to work as a bios for the
underlying hardware the kernel can access it as one would access a
bios in general (ok not entirely the pc emulator already HAS a bios
and would need to be rewritten to better communicate with the browser)
also the source is kinda hard to understand because its minified and
the author either didnt have, or didnt wish to release the un-minified
version. but never the less the idea is there, and much of the
underlying mechanisms are easy enough to understand and it seems to
get a lot of its power from the typed arrays.
Re: Booting to the Web Boris Zbarsky 7/26/11 6:27 AM
On 7/26/11 5:00 AM, Marcos wrote:
> It would be good if packaged applications made use of an open
> standardized format... like W3C Widgets [2] [3]

This would probably be more likely if we hadn't been told to f** off
when Widgets was being developed and we provided feedback, fwiw.

-Boris

Re: Booting to the Web Robin Berjon 7/26/11 6:27 AM
On Jul 26, 2011, at 11:37 , Ben Francis wrote:
> 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.

A lot of manufacturers and telcos are concerned about having to deal with what is essentially a WebKit monoculture (the many minor divergences notwithstanding). I am very much certain that they would react positively to increased competition and would almost certainly back it. But before that, there needs to be something believable that can be shown. I'm not too worried about that part. It's getting from here to something that could ship OEM that's harder.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Booting to the Web Mike Shaver 7/26/11 6:49 AM
On Tue, Jul 26, 2011 at 5:39 AM, Paul [sabret00the]
<sabre...@yahoo.co.uk> wrote:
> Things I'd prefer to see resources devoted to before this:

There are lots of things that Mozilla is working on, virtually all of
them with more resources than B2G.  It's great that you have specific
desires, and useful for you to contribute to scratching them, but this
thread is about B2G and not what else Mozilla could be doing.  It's
going to be busy enough just on that topic, so I'd thank everyone to
start their own threads in appropriate places to propose other work,
or announce the things they're going to be doing.

Thanks,

Mike

Re: Booting to the Web Ken Saunders 7/26/11 6:51 AM
So is this what it was like when the Firefox Project launched?
Exciting, bold, ambitious, daunting, overwhelming, etc and so on? :)
Of course, you probably had a better foundation to work with.

I am so far outside of my element here that I had to leave a trail of
popcorn to find my way out after commenting, but I just want to say
thanks (sincerely), good luck, and you guys freakin' rock! Seriously.

Ken

Re: Booting to the Web Ken Saunders 7/26/11 6:21 AM
Re: Booting to the Web Natanael L 7/26/11 7:03 AM

I started thinking about distributing installable Web App caches
*using Git*. Maybe that's a stupid approach as well, but I think that
could work.

I guess we'd like to have some standardized tags in the repositories,
so that it's easy to see which versions in the history are stable and
which ones are betas.

Also, application signing. Preferably the web apps would be installed
from a single installer file that contains all resources that we need
to store locally. This file would be signed cryptographically. How to
easily combine this with Git is a good question (secondary Git
repository with an installer file for each version (that somebody
bothered to make an installer for), with a pointer to the same version
in the code repository?).

More ideas are coming.

Re: Booting to the Web Chris Jones 7/26/11 7:11 AM
On 07/25/2011 11:55 PM, Tan Yew-wei wrote:
> 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/])

The only networking APIs we expect to expose to content are
XmlHttpRequest and WebSockets, but if you have a compelling use-case
that can't be satisfied by those, please feel free to propose something
new :).  The best place to do that would be the WHATWG mailing list.

Cheers,
Chris

Re: Booting to the Web Chris Jones 7/26/11 7:11 AM
Re: Booting to the Web AaronMT 7/26/11 6:53 AM
Different people work on different things. You're aware of that, right?
Re: Booting to the Web Tan Yew-wei 7/26/11 7:23 AM
Will do. Thanks for the info.
Re: Booting to the Web Mike Shaver 7/26/11 7:45 AM
On Mon, Jul 25, 2011 at 8:28 PM, Nick Dafo <nickdaf...@gmail.com> wrote:
> As a huge Android supporter i dont see why you find the need to do
> this.

You are not the only one to ask this (implied) question, so I
apologize for not making it clearer in the original post.

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

We are certainly going to continue with Firefox on Android.  It's
improving all the time, and in pretty exciting ways.  That's one of
the reasons that we're starting our explorations on Android, in fact.

We don't feel that we can integrate as deeply as we want on stock
Android, for purposes of this project's goals.  We don't want to have
a browser next to the apps, we want to have the apps built with the
web platform, including the system apps like the launcher and the
dialer and SMS app and even the app manager/market itself.

We hope that the resulting APIs and capabilities make their way into
all browsers on all platforms, because they will dramatically increase
the reach of the web; we'll certainly be proposing the successful ones
for standardization, and for in-development feedback.

Mike

Re: Booting to the Web Chris Jones 7/26/11 7:49 AM
On 07/26/2011 05:00 AM, Marcos wrote:
> 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?
>

Mozilla has evaluated a few of the APIs.  They solve of the problems
we're interested in, e.g. Contacts allows querying contacts, but not
all: Contacts doesn't allow updating contacts.  Mozilla has been
involved with Devices before, with at least geolocation, and we would of
course continue as it makes sense for us to.

Cheers,
Chris

Re: Booting to the Web Carlo Daffara 7/26/11 8:01 AM
On Jul 26, 4:45 pm, Mike Shaver <mike.sha...@gmail.com> wrote:

> We don't feel that we can integrate as deeply as we want on stock
> Android, for purposes of this project's goals.  We don't want to have
> a browser next to the apps, we want to have the apps built with the
> web platform, including the system apps like the launcher and the
> dialer and SMS app and even the app manager/market itself.

This is the approach used by Palm (now HP) with its WebOS; the system
services are actually
written in Node.js (a good example is the Contacts service) and most
of the UI is built in HTML5 and JS.
Carlo Daffara

Re: Booting to the Web Eric Dorman 7/26/11 8:04 AM
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/
> > 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

I support this, but security has to be one of the first things in this
OS. I am creating a doc file that addresses my security concerns.

Re: Booting to the Web ya knygar 7/26/11 8:13 AM
> I started thinking about distributing installable Web App caches
> *using Git*. Maybe that's a stupid approach as well, but I think that
> could work.

as i know it's something http://unhosted.org is up to,
along with de-coupling the web app data from web apps themselves.
Their conceptions would likely to be used in FreedomBox's in one
or another way.

I think http://freedomboxfoundation.org mailers has many related
ideas, i mean - i know they have, maybe even these which You
haven't thought about, yet..

Especially in Distributed, Decentralized and Secure systems, i think,
Mozilla team could benefit from their help..

 FBX is *almost* a Debian project and has many
strong sides but web apps isn't among them so,
i think, FBX team could, in the turn, benefit from
Mozilla's help :)

By - that - i'm sure - Mozilla team are  welcome
to discuss any security concerns as the system
B2G would deal with is Linux and Debian community
are among the strongest there.
http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss

Re: Booting to the Web ya knygar 7/26/11 8:22 AM
> This is the approach used by Palm (now HP) with its WebOS; the system
> services are actually
> written in Node.js (a good example is the Contacts service) and most
> of the UI is built in HTML5 and JS.

just as you'v mentioned,
i think - when HP would
compete with MS on it's
own market, it's
likely that WebOS would
became an App for Win8.
So there would be a platform
in platform, just like a part of
B2G could be (potentially)

As long as it all would finally,
(potentially) support W3C/IETF
work and standards - building
web apps platforms, it's cool,
i think. As - as long as Mozilla
is good in web, there is chance
for a  real Moz OS competing
with proprietary and even closed
one's.

Re: Booting to the Web Benoit Jacob 7/26/11 8:28 AM
2011/7/25 Mike Hommey <m...@glandium.org>:
> On Mon, Jul 25, 2011 at 01:23:45PM -0400, Mike Shaver 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?
>>
>> 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.
>
> 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...

The recent Android devices I've seen all supported OpenGL ES 2.0 well;
that's all we should need.

Benoit

Re: Booting to the Web ya knygar 7/26/11 8:32 AM
> And how about starting from the OpenMoko O.S.? I think it could be
> more useful than Android. Or even NetBSD as the core of the final
> system.

+1 i have proposed http://wiki.openmoko.org/wiki/SHR
there are misleading info, i think,
that there aren't FLOSS mobile systems
that could compete easily, that's why Android
is here, and it's best and "real" among these "academic"
projects,
i think it's not true, i think Android is pre-installed
(in some - almost firmwared)
on every second mobile by other reasons :)

Re: Booting to the Web Mike Shaver 7/26/11 8:34 AM
On Tue, Jul 26, 2011 at 11:32 AM, ya knygar <kny...@gmail.com> wrote:
>> And how about starting from the OpenMoko O.S.? I think it could be
>> more useful than Android. Or even NetBSD as the core of the final
>> system.
>
> +1 i have proposed http://wiki.openmoko.org/wiki/SHR

Please see my post in this thread about OS selection.  Experimental
results for bringing up capable systems on available hardware are
welcome, but abstract advocacy isn't helpful at this stage.

Thanks,

Mike

Re: Booting to the Web ya knygar 7/26/11 8:57 AM
> Please see my post in this thread about OS selection.  Experimental
> results for bringing up capable systems on available hardware are
> welcome, but abstract advocacy isn't helpful at this stage.

I have just read (again) all your posts on topic,
and - still - can't understand how i can help more on Experimental results-
for B2G in current situation..

You'v said


> It's great that you have specific
> desires, and useful for you to contribute to scratching them, but this
> thread is about B2G and not what else Mozilla could be doing.

I think - underlying kernel and platform of B2G so it have  started and
would be mentioned in Mass Media like a Mozilla OS (no, really)
is important enough to
start a separate topic about such an essential aspects,

 would you create one?

if people from B2G team would describe:

what existing OS's you have evaluated for use in B2G
with detail analyze if there where, any -

so we - who talk about existing mobile OS's to build from:
could discuss and help - starting from what You as a Mozilla
OS team have, not from the scratch and own, separate, project.?

Thanks in advance.

Re: Booting to the Web Robin Berjon 7/26/11 9:44 AM
On Jul 26, 2011, at 16:03 , Natanael L wrote:
> On Jul 26, 3:17 pm, Robin Berjon <ro...@berjon.com> wrote:
>> In my fantasy world we could get the BOBW by using git as the application distribution format (naturally with a UI that doesn't scare people away). It certainly has properties that are more interesting than either AppCache or Widgets. And it shouldn't be excessively painful to implement either. Using its HTTP protocol, we might just be able to transparently tie-in web sites as well.
>
> I started thinking about distributing installable Web App caches
> *using Git*. Maybe that's a stupid approach as well, but I think that
> could work.
>
> I guess we'd like to have some standardized tags in the repositories,
> so that it's easy to see which versions in the history are stable and
> which ones are betas.

That's certainly something I had in mind, but I don't think that it requires any manner of standardisation. Tags are mostly text and if you want to release an app in which people can easily pick which version they want to run you just use sensible labels. There could be some localisation implications but frankly I'd be delighted to worry about that problem if the rest falls into place.

> Also, application signing. Preferably the web apps would be installed
> from a single installer file that contains all resources that we need
> to store locally. This file would be signed cryptographically. How to
> easily combine this with Git is a good question (secondary Git
> repository with an installer file for each version (that somebody
> bothered to make an installer for), with a pointer to the same version
> in the code repository?).

Git supports signed commits (using GPG) but I don't think that gives you the signing you're looking for. That being said, signing is a good example of a technical solution that's often misused. All that signing gives you is the fact that a bunch of bytes really come from a given digital identity but that's almost entirely useless without some form of trust architecture to back it. If you can figure out workable trust, then signing will just be an implementation detail.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Booting to the Web Natanael L 7/26/11 9:52 AM
On Jul 26, 6:44 pm, Robin Berjon <ro...@berjon.com> wrote:
> On Jul 26, 2011, at 16:03 , Natanael L wrote:
>
> > On Jul 26, 3:17 pm, Robin Berjon <ro...@berjon.com> wrote:
> >> In my fantasy world we could get the BOBW by using git as the application distribution format (naturally with a UI that doesn't scare people away). It certainly has properties that are more interesting than either AppCache or Widgets. And it shouldn't be excessively painful to implement either. Using its HTTP protocol, we might just be able to transparently tie-in web sites as well.
>
> > I started thinking about distributing installable Web App caches
> > *using Git*. Maybe that's a stupid approach as well, but I think that
> > could work.
>
> > I guess we'd like to have some standardized tags in the repositories,
> > so that it's easy to see which versions in the history are stable and
> > which ones are betas.
>
> That's certainly something I had in mind, but I don't think that it requires any manner of standardisation. Tags are mostly text and if you want to release an app in which people can easily pick which version they want to run you just use sensible labels. There could be some localisation implications but frankly I'd be delighted to worry about that problem if the rest falls into place.

Maybe XML or JSON as comments in the Git history? Or ini file
structure. Anything, really.
As long as we can put a note that the installer can understand, then
everything should be just fine.

> > Also, application signing. Preferably the web apps would be installed
> > from a single installer file that contains all resources that we need
> > to store locally. This file would be signed cryptographically. How to
> > easily combine this with Git is a good question (secondary Git
> > repository with an installer file for each version (that somebody
> > bothered to make an installer for), with a pointer to the same version
> > in the code repository?).
>
> Git supports signed commits (using GPG) but I don't think that gives you the signing you're looking for. That being said, signing is a good example of a technical solution that's often misused. All that signing gives you is the fact that a bunch of bytes really come from a given digital identity but that's almost entirely useless without some form of trust architecture to back it. If you can figure out workable trust, then signing will just be an implementation detail.

The entire point is that there should be *some* signature that can
make sure that what you install comes from the real author. For
example, on Android, if you install an app that has the package name
com.site.appname and you then try to install another one with the same
package name, it must be signed with the same key. Updates are just
APK installer files too. When updates are installed, that's what
happens. If the key changes you must uninstall the previous versions
first.

If we have an app store, these keys should be visible there and be
easy to confirm. Devs who have GPG keys since before could reuse those
with a minimal effort.

Trust here is essentially to verify the signature and verify that the
key belongs to a developer you trust.

Re: Booting to the Web Robin Berjon 7/26/11 10:07 AM
On Jul 26, 2011, at 11:00 , Marcos wrote:
> 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?

I don't think that the most interesting question is what DAP has done so much as what it could do provided an iteration loop with B2G. DAP has experimented with a number of approaches in this space and I wouldn't recommend that someone just jump into DAP's documents without a little bit of prior information because a number of the documents are completely abandoned (I should probably take the time to flag that much more visibly) and others that are active may not reflect the current intentions of the group due to it being frequently short on resources. Feel free to direct questions, rants, or anything that seems wrong to me (or directly to the group).

In no particular order, things that are on DAP's plate that may be of direct interest here are:

• A way of describing HTTP services using WebIDL. This is particularly useful in order to combine the formal description availed to us by WebIDL (with its tooling, understood semantics, tests generation, etc.) with APIs that work irrespective of whether they're provided locally or remotely. A good example of this is Contacts. The prototypes that Labs made had multiple backends to get the contacts information from, but that required writing such backends and including them in the implementation somehow. It would be simpler if the various sources could expose a Contacts API directly, and if the same API could get at the local contacts database(s). This is relatively simple so long as it doesn't have to be general; expect code from me in the coming weeks. I'd expect Contacts to be recast as that shortly (as well as other APIs of the same metal like Calendar or Tasks). If you want contact updates, this might just make them easier to support as well since the source which needs updating is more easily known without having to expose it at the JS API level, which gets clunky fast.

• Web Introducer or something like it (there are bits and pieces lying around a bit everywhere), http://web-send.org/introducer/. This has been planned for inclusion in DAP for a while (I won't bore you with the details). It provides an elegant model to expose the kind of service mentioned in the previous paragraph to an application in a secure manner.

• Discovery on the local network. There's a proposal at http://lists.w3.org/Archives/Public/public-device-apis/2011Jul/0073.html. A lot of magic can be done with this. Note that while the proposal doesn't include that, it could also allow for local applications to expose themselves as services on the local network.

• Smaller bits and pieces of "devicey" things like battery level or vibration support.

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

As I said earlier, I think that it would be best to look at what's needed before entering a discussion of which standard is most appropriate here. I think Boris's reaction only strengthens my point :)

In that respect, I think that this email from Mike Hanson can be a useful starting point for a discussion:

    http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0159.html

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Booting to the Web Paul [sabret00the] 7/26/11 10:14 AM
Of course.
Re: Booting to the Web Paul [sabret00the] 7/26/11 10:14 AM
Of course.
Re: Booting to the Web Natanael L 7/26/11 10:37 AM
On Jul 26, 7:07 pm, Robin Berjon <ro...@berjon.com> wrote:
[...]

> • A way of describing HTTP services using WebIDL. This is particularly useful in order to combine the formal description availed to us by WebIDL (with its tooling, understood semantics, tests generation, etc.) with APIs that work irrespective of whether they're provided locally or remotely. A good example of this is Contacts. The prototypes that Labs made had multiple backends to get the contacts information from, but that required writing such backends and including them in the implementation somehow. It would be simpler if the various sources could expose a Contacts API directly, and if the same API could get at the local contacts database(s). This is relatively simple so long as it doesn't have to be general; expect code from me in the coming weeks. I'd expect Contacts to be recast as that shortly (as well as other APIs of the same metal like Calendar or Tasks). If you want contact updates, this might just make them easier to support as well since the source which needs updating is more easily known without having to expose it at the JS API level, which gets clunky fast.
>
> • Web Introducer or something like it (there are bits and pieces lying around a bit everywhere), http://web-send.org/introducer/. This has been planned for inclusion in DAP for a while (I won't bore you with the details). It provides an elegant model to expose the kind of service mentioned in the previous paragraph to an application in a secure manner.

I think that his resembles Intents in Android. Essentially the apps
installed can use a system API to provide their own custom API:s. Like
how Barcode Reader can supply barcode reading functionality to other
apps without this being explicitly a part of Android. It's the API for
apps to provide API:s that make it possible.
To get/update/sync contact information is slightly different if you've
got standard API:s already, then all you have to do is to tell the OS
about the sources. It seems like the Introducer documents deals with
that.
But there's still the possibilty to write this in such a way that you
can handle all these things (calendar, contacts, etc) with the same
basic set of API:s (but I'm unsure on how well this approach would
work). By that I mean so that the OS itself does not care about
contacts and all that, it rather handles this *type* of information.
If the user have two contacts apps (default + fancy one?), they both
use the same contacts API and registers something like a *local
database of the contacts type*, then the OS manages that database
according to default API:s. Then the contact apps provides the
contacts API:s to other apps.
You could then register all kinds of things. Geolocation log, notes,
anything.
I am aware that this could end up VERY messy since you'd need a highly
flexible database and fragmentation in API:s is likely (at least
initially).

What do you think? Does this make sense?

Re: Booting to the Web Mike Shaver 7/26/11 10:42 AM
On Tue, Jul 26, 2011 at 11:57 AM, ya knygar <kny...@gmail.com> wrote:
> and - still - can't understand how i can help more on Experimental results-
> for B2G in current situation..

It's quite possible that you can't, in which case you could wait until
it's possible -- until you can fork something workingish and play with
it, or until you know how hard it is to bring up these other OSes on
modern commodity hardware.  The abstract advocacy isn't any more
useful just because you don't yet have data to provide!

> what existing OS's you have evaluated for use in B2G
> with detail analyze if there where, any -

Assume that there was very little, because our needs (as enumerated a
couple times) are met by this selection.  At this stage of
development, we need "sufficient", not "optimal".  The underlying
kernel is just about the least important aspect of this project, even
if it's something we need early on: how we approach the new APIs,
application interaction model, security model (!), etc. are much more
important.

> so we - who talk about existing mobile OS's to build from:
> could discuss and help - starting from what You as a Mozilla
> OS team have, not from the scratch and own, separate, project.?

My advice is to wait until someone gets something up on one OS -- the
few of us working on B2G now are going to start from Android; a
sideline into starting from ChromeOS might be interesting as well,
since it's a much more open stack -- and then we (incl you) will know
more about what we need, and there'll be something to compare to.

Mike

Re: Booting to the Web Robin Berjon 7/26/11 10:51 AM
Replying to self, since I forgot the most important part.

On Jul 26, 2011, at 19:07 , Robin Berjon wrote:
> I don't think that the most interesting question is what DAP has done so much as what it could do provided an iteration loop with B2G. DAP has experimented with a number of approaches in this space and I wouldn't recommend that someone just jump into DAP's documents without a little bit of prior information because a number of the documents are completely abandoned (I should probably take the time to flag that much more visibly) and others that are active may not reflect the current intentions of the group due to it being frequently short on resources. Feel free to direct questions, rants, or anything that seems wrong to me (or directly to the group).
>
> In no particular order, things that are on DAP's plate that may be of direct interest here are:

On top of this, any work item that this project sees as ripe for standardisation and that can be fitted into the charter is very welcome. Implementation-driven work would have no problem getting to the top of the group's priority list.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Booting to the Web Natanael L 7/26/11 11:33 AM

On the security model, this deals with what I was thinking of:
http://www.scribd.com/doc/29085880/Fine-grained-Resource-Usage-Model-for-Android-Paper
There's more of these. There's been a few different patches already to
enhance the security model in Android.

Re: Booting to the Web Andreas Doerr 7/26/11 11:38 AM
> > But either way there's a bit of code to write before such refinements :)
>
> And how!  Please help!

Let's say I want to contribute once some code becomes available and/or
work packages have been defined. What is the best way to get prepared?
Become familiar with Fennec for Android?


Thanks,
Andreas

Re: Booting to the Web David Illsley 7/26/11 11:44 AM
Sounds like fun. How radical (or not) do you see it being? i.e. Is the first goal to get a bunch of apps with squareish icons on a grid?
David

On 25 Jul 2011, at 16:49, Andreas Gal 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
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Re: Booting to the Web Mike Shaver 7/26/11 11:46 AM
On Tue, Jul 26, 2011 at 1:37 PM, Natanael L <natan...@gmail.com> wrote:
> I think that his resembles Intents in Android.

Yeah, we're thinking along those lines as well:

http://mozillalabs.com/blog/2011/07/web-apps-update-experiments-in-web-activities-app-discovery/

Mike

Re: Booting to the Web Joao Americo Santos - Clark 7/26/11 1:41 PM
On Jul 25, 4: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/
> > 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

What programming language you guys use on board?

Re: Booting to the Web Chris Jones 7/26/11 2:58 PM

That's a great way to get started, especially by choosing some simple
bugs[1] and fixing them.  This[2] lists the few other items we have
right now, *many* more to come in the near future.

Cheers,
Chris

[1] https://bugzilla.mozilla.org
[2] https://wiki.mozilla.org/B2G#Contributing

>
> Thanks,
> Andreas
>

Re: Booting to the Web Gervase Markham 7/26/11 3:05 PM
On 25/07/11 08:49, Andreas Gal wrote:
> 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.

We should talk to litl:
http://www.litl.com/
http://en.wikipedia.org/wiki/Litl

They appear to have done something which looks (from reading their web
pages) very much like an OS which boots to a browser. Havoc Pennington,
open source uber-hacker, is their Director of Software Development.
There may well be opportunities for collaboration.

Gerv


Re: Booting to the Web Chris Jones 7/26/11 3:13 PM
The goals of the B2G project are lower level, adding new APIs to the web
platform and realizing them on a standalone OS on real hardware.  Time
will tell what the impact of B2G (if any) is.

Cheers,
Chris

Re: Booting to the Web Chris Jones 7/26/11 3:13 PM
The goals of the B2G project are lower level, adding new APIs to the web
platform and realizing them on a standalone OS on real hardware.  Time
will tell what the impact of B2G (if any) is.

Cheers,
Chris

On 07/26/2011 02:44 PM, David Illsley wrote:

Re: Booting to the Web Gervase Markham 7/26/11 3:20 PM
On 26/07/11 02:37, Ben Francis wrote:
> I'm the founder of the Webian project.

Hi Ben,

Great to hear from you :-)

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

Such partnerships are not, I am sure, out of the question. :-)

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

My take (and I'm not one of the people who launched this project): I
doubt Mozilla would ever ship its own hardware, but if by
"consumer-facing", you mean "could be put in the hands of consumers with
minimal customization", then absolutely.

Gerv

Re: Booting to the Web Gervase Markham 7/26/11 3:25 PM
On 26/07/11 04:33, David Rusling wrote:
> Anything that Linaro can help with?

Hi Dave,

We want our ARM performance to be awesome. Can you help? :-)

http://www.aminutewithbrendan.com/pages/20110721 :
"ARM already is supported well by our JavaScript engine, but we want to
be make our code tight on ARM, as fast as possible."

Gerv

Re: Booting to the Web AwesomeSauce 7/26/11 4:07 PM
On Jul 25, 8:49 am, 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

Mozilla will cease to exist long before this project is completed.

Re: Booting to the Web Phil Taylor 7/26/11 6:06 PM
On Jul 25, 1:36 pm, Chris Jones <cjo...@mozilla.com> wrote:

> On 07/25/2011 01:29 PM, Bert Freudenberg wrote:
>
> > 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?
>
> 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

I hope you are planning on supporting NPAPI plugins?
We are building an NPAPI plugin to enable the development of high-
performance multi-threaded web applications.
Our goal is to eliminate the performance gap between web apps and
native apps, without bringing desktop development tools to the web
developers(think NaCL). We have a Google Tech talk that goes over the
how on our website.

www.fabric-engine.com

We are starting off by building high end DCC tools for the film
industry, but the solution is a generic threading architecture +
rendering + interaction. We are also still at alpha.

Phil

Re: Booting to the Web fm 7/26/11 7:55 PM
On Jul 26, 1:27 am, Mike Shaver <mike.sha...@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 1:19 PM, 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
> > 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

heh, its interesting to see what graphics stack will be used and what
the security solutions.  its both hard things

Re: Booting to the Web anix 7/26/11 11:19 PM
APIs sounds cool... If those APIs are something like a JS type or
node.js kind of would be gr8 ..and can attract more web developers...

eagerly waiting to see a prototype... :D

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

Re: Booting to the Web A Pro 7/27/11 12:15 AM

You should first fix buggy Firefox, versions after 1.5 are Mozilla's
embarrassment. Your thinking is weird. If OS has to be based on
Firefox, then browser should be programmed well.

If OS will be like new Firefox, you have 100% chance of fail.

Aaaa... wait a minute. You propably want to reply me, that I should
report FF bugs? Maybe you should start using Firefox and you will see,
Firefox is not ready for daily using, even at home. Write all basic
functions again instead of wasting time for themes and other
irrelevant functions for kids, because now both projects (FF and B2G)
are amateur work. Start doing things serious.

Best Regards,
A pro

unk...@googlegroups.com 7/27/11 12:08 AM <This message has been deleted.>
Re: Booting to the Web Robin Berjon 7/27/11 2:00 AM
On Jul 27, 2011, at 00:05 , Gervase Markham wrote:
> We should talk to litl:
> http://www.litl.com/
> http://en.wikipedia.org/wiki/Litl
>
> They appear to have done something which looks (from reading their web
> pages) very much like an OS which boots to a browser. Havoc Pennington,
> open source uber-hacker, is their Director of Software Development.
> There may well be opportunities for collaboration.

As far as I can tell the litl actually uses Flash for its apps. Not that they may not have had good ideas anyway, but they might require some adaptation.

--
Robin Berjon - http://berjon.com/ - @robinberjon

Re: Booting to the Web ya knygar 7/27/11 2:49 AM
> There may well be opportunities for collaboration.

I think - they may pre-install the W2G into their hardware,
they, even, may(!) be glad - to be first - shipping Mozilla OS.

There are other companies and "parties", i know (on East European market)
 - that may benefit from easily customizable(! editions, not general purpose)
 tablet and mobile OS,

i think - they would (rather sooner than later, if Mozilla's team
won't hesitate to promote and target resources to this project) -

 happily use Mozilla's OS as far as it would provide the possibility
of easily customizable environment - that CSS/HTML/JS styling and
actual app developing - promises (maybe with future, user-friendly IDE's,
constructors, but, anyway).

Now  - among these i know - they work with Android, because of it's like
"forced" "industrial standard"
not because it nicely fits their custom needs. I can't elaborate
widely on this "forcing",

but - i'm sure of and i could propose - certain pathways to possible
distributives that may be (may be, if "forcing" won't be too hard)
 developed with interested institutions
and companies in my region..
 if it won't be considered as useless advocacy.)

I wonder if Mozilla team considered such "markets" (of white-label hardware
and custom OS's like for education etc. ) on early planning
of B2G mash-up
and if their existence were reviewed as a possibility for pre-installing.

Also - i'm curious - if Mozilla employees could start this kind
project independently,
or, only, after a discussion and strategy planning with "higher
instances" of corporation?

Re: Booting to the Web Marcos 7/27/11 2:50 AM
On Jul 26, 3:27 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 7/26/11 5:00 AM, Marcos wrote:
>
> > It would be good if packaged applications made use of an open
> > standardized format... like W3C Widgets [2] [3]
>
> This would probably be more likely if we hadn't been told to f** off
> when Widgets was being developed and we provided feedback, fwiw.

I am sorry that I gave you and Moz that impression and that I offended
you. I have done everything I can from a specification perspective to
address Mozilla's concerns to open the door to address the issues
Mozilla had with the specs:

  1. I've made XML Signatures one of the possible signature formats,
opening the door to use whatever alternative is better.
  2. Made the XML config format one of the possible configuration
formats (or serializations): this opens up the door to using JSON.

I'm happy to work with Mozilla on fixing the above (or getting out of
the way, if it's me as editor that is the problem).

Re: Booting to the Web Robert Kaiser 7/27/11 6:12 AM
Natanael L schrieb:
> Indeed, we could have very exiting UI:s! Mozilla OS should REALLY be
> split up in modules, the platform and the interface should be
> separated. Integration between the two should be done with API:s that
> ANY app can use.

I don't think there's any plan on OS UI for B2G yet, the focus is mostly
on getting the needed web standards up so web apps can do everything
that "native" apps can. Everything else is probably an afterthought
right now, but surely something where contributions are welcome.

> Then things differ: Where Ubuntu use X (soon Wayland?) and GNU
> software, there will be Chromeless on Mozilla OS.

Wrong. Chromeless is not a graphics environment, it still needs
something like X or Wayland or whatever in between, AFAIK.

> Where Ubuntu use Gnome, there will be the Mozilla OS interface, built
> in HTML+JS.

Probably, but I don't think there are any plans on how that is
structured or laid out. Also, for a tablet OS, not very much is needed
at that level - the less, the better, in the end.

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! :)

Re: Booting to the Web Robert Kaiser 7/27/11 6:15 AM
ya knygar schrieb:
> My, personal, opinion - Intel would be strong enough on mobile market
> with open source

And Intel will strongly continue to push on MeeGo, with a mobile stack
that is as open as achievable. I personally hope they will be successful
and come out with something stable enough that Mozilla will be able to
build on that at least in addition.

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! :)

Re: Booting to the Web Robert Kaiser 7/27/11 6:19 AM
Carlo Daffara schrieb:
> This is the approach used by Palm (now HP) with its WebOS; the system
> services are actually
> written in Node.js (a good example is the Contacts service) and most
> of the UI is built in HTML5 and JS.

 From what I know, HP has no interest in doing cross-browser- and
cross-OS-usable open web standards there, or apps that really run from
the web, which is the main weakness of their approach and main
difference to what Mozilla wants to do there. We are seeing our efforts
mainly as a way to develop the necessary open web standards to run
_real_ web apps to do everything you need on a mobile device.

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! :)

Re: Booting to the Web Robert Kaiser 7/27/11 6:22 AM
Phil Taylor schrieb:

> I hope you are planning on supporting NPAPI plugins?

I actually think we should kill support for NPAPI completely. Running
binary application within a non-webby area and making people believe
this has any connection to being "the web" is plainly wrong.
Unfortunately there's too much legacy around to kill it right away,
which makes me cry almost every day.

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! :)

Re: Booting to the Web Robert Kaiser 7/27/11 6:34 AM
A Pro schrieb:

> If OS will be like new Firefox, you have 100% chance of fail.

Right, if it's as successful as current Firefox, it will only have a few
hundreds of millions of users, surely too little to claim that anything
there works or was a good move. Thanks for reminding us.
We should abandon this just like we did abandon Firefox and openness,
innovation and opportunity on the web in general.

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! :)

Re: Booting to the Web Ben Francis 7/27/11 6:38 AM
On Wednesday, July 27, 2011 2:12:05 PM UTC+1, Robert Kaiser wrote:
> I don't think there's any plan on OS UI for B2G yet, the focus is mostly
> on getting the needed web standards up so web apps can do everything
> that "native" apps can. Everything else is probably an afterthought
> right now, but surely something where contributions are welcome.

I get that the APIs and the small footprint OS are currently the most unique parts of the project, but I think the UI of a modern mobile OS needs to be a little more than an afterthought going forward :)

Re: Booting to the Web Robert Kaiser 7/27/11 6:38 AM
David Rusling schrieb:

> Anything that Linaro can help with?

I think what Gerv says about ARM and maybe in the longer terms, once we
have some basic stuff that work in the project, some help to get to a
more lean and hopefully even more open lower-level OS stack than Android
while keeping compatibility with a good amount of current tablet
hardware would be things we surely can need help with. Mozilla doesn't
really have much experience with lower levels of OSes and I don't think
we want to invest too much there ourselves (I'm not on the B2G team,
people working there might differ from my opinion slightly and are
probably a better source of info in the end).

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! :)

Re: Booting to the Web Mike Shaver 7/27/11 6:49 AM
On Wed, Jul 27, 2011 at 9:38 AM, Ben Francis <b...@tola.me.uk> wrote:
> I get that the APIs and the small footprint OS are currently the most unique parts of the project, but I think the UI of a modern mobile OS needs to be a little more than an afterthought going forward :)

Yes, exactly so.  The point of the APIs is to let web technology be
used to create great experiences, so we need to make sure we're
planning -- and others are planning -- those experiences.  That way
we'll know what we need to build, and we'll know how well we've done.

Booting to a <browser> and location bar on a device is a first step
and parlour trick, not a strategy for moving the web (and other
stacks) forward.

Mike

Re: Booting to the Web Robert Kaiser 7/27/11 6:50 AM
Robin Berjon schrieb:
> A lot of manufacturers and telcos are concerned about having to deal with what is essentially a WebKit monoculture (the many minor divergences notwithstanding).

 From what I heard, their problem is less that it's WebKit, but more
that one single company has control over the software they are shipping.
Even if there's one or two somewhat larger other players in the
smartphone market atm, one of them is confined to their self-produced
devices (and using WebKit as well, as a side note), which at least
doesn't help manufacturers, and the other has yet to have a larger
impact on the market (but history has taught us that even if the people
in Redmond might take longer, they eventually get something out that
matters).
And even if the latter one might have some impact some time, the
pressure seems to be rising from manufacturers and telcos to see
something emerge where they can have more influence on what's on the
device. Not sure if we even want to provide them that story, though.

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! :)

Re: Booting to the Web Mike Shaver 7/27/11 6:56 AM
On Wed, Jul 27, 2011 at 9:15 AM, Robert Kaiser <ka...@kairo.at> wrote:
> ya knygar schrieb:
>>
>> My, personal, opinion - Intel would be strong enough on mobile market
>> with open source
>
> And Intel will strongly continue to push on MeeGo, with a mobile stack that
> is as open as achievable.

Intel also has public plans around Android for x86, to ship this year,
so there are going to be lots of options.

May this be the last OS-speculation post we see before something boots!

Mike

Re: Booting to the Web Mike Shaver 7/27/11 7:31 AM
On Tue, Jul 26, 2011 at 9:06 PM, Phil Taylor <mrph...@gmail.com> wrote:
> I hope you are planning on supporting NPAPI plugins?
> We are building an NPAPI plugin to enable the development of high-
> performance multi-threaded web applications.
> Our goal is to eliminate the performance gap between web apps and
> native apps, without bringing desktop development tools to the web
> developers(think NaCL). We have a Google Tech talk that goes over the
> how on our website.

We would strongly prefer to not rely on proprietary plugins,
especially not for infrastructure like a threading model.  We also aim
to eliminate the performance gap, though it obviously depends on the
application.  I don't think that film-grade DCC is likely to be an
early target for a device-targetted OS project.

(I love the tech in question, as I think you know, but I don't see it
as a good fit
for something like B2G unless you're aiming towards standardized APIs
and multiple implementations.)

Mike

Re: Booting to the Web Robert Kaiser 7/27/11 7:34 AM
Ben Francis schrieb:

Once the thought comes to actually make a product, the UI needs to be
designed and thought through for sure. Fore now, I think there's so much
to do to get the APIs done that even the small footprint should not
necessarily a real focus yet.
Remember that this is not at the stage where we can even think of a
product, it's the start of an early experiment that maybe some time
could lead to a product if we're lucky - but it should first and
foremost lead to open web standards that bring everyone forward. :)

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! :)

Re: Booting to the Web Robert Kaiser 7/27/11 7:35 AM
Mike Shaver schrieb:

> May this be the last OS-speculation post we see before something boots!

Hehe, I understand the hint ;-)

And yes, let's get some code there first and work on what we can do
best, namely the needed web standards! :)

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! :)

Re: Booting to the Web Mike Shaver 7/27/11 7:35 AM
On Tue, Jul 26, 2011 at 6:05 PM, Gervase Markham <ge...@mozilla.org> wrote:
> They appear to have done something which looks (from reading their web
> pages) very much like an OS which boots to a browser. Havoc Pennington,
> open source uber-hacker, is their Director of Software Development.
> There may well be opportunities for collaboration.

We have lots of connections to the litl folks (and 2 of our newest
hires at Mozilla came from litl), but I don't think their stuff is
quite what you think it is.  They boot into a Clutter-based/GNOME UI,
and have a separate browser (based on XULRunner).

Mike

Re: Booting to the Web Mike Shaver 7/27/11 7:40 AM
On Wed, Jul 27, 2011 at 10:34 AM, Robert Kaiser <ka...@kairo.at> wrote:
> Once the thought comes to actually make a product, the UI needs to be
> designed and thought through for sure. Fore now, I think there's so much to
> do to get the APIs done that even the small footprint should not necessarily
> a real focus yet.

No, building a platform without apps and experiences to guide it is a
recipe for sky-castle disaster, IMO.  We should be choosing the next
(first) handful of apps or experiences that we want to build towards,
filling in the platform for that, and then repeating.

We'll no doubt need to revisit APIs, implementations and the user
experience many times, but it'll almost certainly be better for them
to iterate together.

Mike

Re: Booting to the Web Mike Hommey 7/27/11 7:51 AM
Just a thought. I saw several people mention X or Wayland for display.
I don't see why there would be any need for that actually, if the
browser is the sole graphical application running on the system. In
fact, gecko could use the framebuffer (as in /dev/fb0) directly,
at some point.

Mike

Re: Booting to the Web Mike Shaver 7/27/11 7:55 AM

I would be surprised if we wanted to only have a single process with
graphics access, but even if we did that process will want to have at
least GLES capabilities.

We need to dig more into the Android driver/API model here and see
what our choices are, before we get too far into X or Wayland.
ChromeOS uses X, and I think they'll do that on tablets and phones as
well, so it might be viable if you can really control the hardware on
the other end.  We may not have (or want, or be able to get) such
tight coupling to the device manufacturers in our case, though.

Mike

Re: Booting to the Web Boris Zbarsky 7/27/11 7:55 AM
On 7/27/11 5:50 AM, Marcos wrote:
> I am sorry that I gave you and Moz that impression and that I offended
> you.

It wasn't a matter of offense.  It was just that it was made quite
explicit back when I tried to provide feedback on Widgets that the goals
of Widgets were not compatible with our goals and hence that the
feedback will not be taken into account.

Which is fine, but the result is that Widgets may or may not be usable
for our purposes.  To the extent that it is, we should consider using
it, but I don't think that we should put a lot of time into fitting
square pegs into round holes...

>    1. I've made XML Signatures one of the possible signature formats,
> opening the door to use whatever alternative is better.
>    2. Made the XML config format one of the possible configuration
> formats (or serializations): this opens up the door to using JSON.

These are recent minor issues, sure.  Not quite related to what I'm
talking about above.

-Boris

Re: Booting to the Web ya knygar 7/27/11 8:04 AM
> the UI needs to be designed and thought through for sure.

How about UI that are given by these Full-screen Web Apps, that are
installed - from which you like, whole OS - like a bundle..

There would be a security problems, malware, etc. But isn't - giving
the control and device API's of the devices to Web Apps is the scope
of this project?

Think of "every" Moz Web App like a container with a skin for a GUI,
maybe, along with some battery bar if there are some accessibility
constrains, but, it's better to use the  modes than
to try to fit UI/UX to everyone's joy.
I'v had many examples and reviews about - how it's uncomfortable -
when you can't include the clock/signal/battery in game/experience,
even - so that bar could be just hided.

i think it all could be based on web standards so = potentially -
fully  inter-reusable , if not,
developers could have a choice of not "Full-sceening the expirience"

there are groups and recommendations like
http://www.w3.org/TR/2011/PR-ccxml-20110510/ and many more in the mix.

Also - programs - developed by independent teams of professionals and
could be better than these - which would be proposed and developed by
relatively small Mozilla team.

To explain in different way:

APP is what controls the OS GUI and device through carefully designed
API's - in the moment,
another tab - another APP - another experience.

Of-course it could be frustrating but it's what we have on every site
now and it's OK for people, along with - an obvious demand for
LessChrome, voice control etc.

what do You think?

i could explain further this variant, if you wish, here is a lot of
place for maneuver.


> From what I heard, their problem is less that it's WebKit, but more that one single company has control over the software

Well, webkit.org it's an Apple's project for Apple's needs,
obviously - when Google forked it - they have to spent a few years to
tailor it for their needs, before the release.
Apple had their years to tailor KHTML, respectively.


 Speaking of XULRunner - it's clear that - using it as a platform has
particular dev speed advantages along with control, centralized
bug-tracking and developers system. (along with disadvantages, that
seems like based on Mozilla's lack of resources, but it's another
story)

So - of-course - for a major companies, manufactures - having to deal
with potential B2G goods could be more pleasant experience than trying
to deal with Apple or Google or etc.


WebKit is a very un-consistent project if you'd look into difference
of mobile browsers based on it - like -
http://www.quirksmode.org/webkit.html


If - like a part of B2G project - Mozilla will provide the more stable
and reusable mobile web engine that could be reused by manufactures of
custom devices and custom OS's (based on B2G or not) - that would,
potentially, lead to a great Open Web future Mozilla is about.


--
To say - if iOS, BBOS, WinMobile for one or another reason won't have
mobile Mozilla - in foreseeable future :
there are half a world market on East where no BBOS nor iOS - aren't
used. Here is - even Android - ain't so popular to have a specific
offices or particular strategy of domination. Here is now and will be,
i hope, a market of hardware devices from Asia, that are used and
would be used with what is best and have demand. And Web Apps based on
latest "W3C tech" have a Huge demand that Androids with outdated
WebKit can't handle now.

There are Mozilla Community that could do what it has will to, even if
it would be a "breaking of rules".

Re: Booting to the Web Mike Hommey 7/27/11 8:13 AM

AFAIK, Android uses the framebuffer directly.

Mike

Re: Booting to the Web Robert Kaiser 7/27/11 8:30 AM
Mike Shaver schrieb:

What I meant was very much in line with what you are saying - we need to
go to create the use-cases for the new web APIs first and work on
getting those both spec'd out and implemented (probably hand in hand) as
a main priority. As long as we're not making this a full consumer
product, we don't need to create the full details of a UX story, we
don't need to think about the *exact* look-and-feel, just about that
that we keep opportunities open to make a compelling on with the APIs
and apps we need to come up with.
Once we're further down the road on being able to do all kinds of
things, we might need to form this in a more complete UX picture, but
starting off with thinking that detailed UX story through, as might have
been suggested here, is probably not where we should go at this time -
actually, _that_ would be a sky-castle. ;-)

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! :)

Re: Booting to the Web Robert Kaiser 7/27/11 8:37 AM
Mike Shaver schrieb:

> We need to dig more into the Android driver/API model here and see
> what our choices are, before we get too far into X or Wayland.
> ChromeOS uses X, and I think they'll do that on tablets and phones as
> well, so it might be viable if you can really control the hardware on
> the other end.  We may not have (or want, or be able to get) such
> tight coupling to the device manufacturers in our case, though.

Of course they use X right now, because Wayland isn't usable enough yet,
but it will come there and be more lean with a better GL story.
For now, I don't think it helps to lose any sleep over those decisions,
it's better to get some code done on Android and keep the options open
to expand to other bases later as they make sense. We're when when we
create code, and once it's there, we have something all those
enthusiasts can try out on other bases and tell us if something works
even better in practice than what we start our work with. :)

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! :)

Re: Booting to the Web A Pro 7/27/11 10:24 AM
On 27 Lip, 15:34, Robert Kaiser <ka...@kairo.at> wrote:
> A Pro schrieb:
>
> > If OS will be like new Firefox, you have 100% chance of fail.
>
> Right, if it's as successful as current Firefox, it will only have a few
> hundreds of millions of users, surely too little to claim that anything
> there works or was a good move. Thanks for reminding us.
> We should abandon this just like we did abandon Firefox and openness,
> innovation and opportunity on the web in general.

Yeah, great example, Robert. "Hundreds of millions of users" is very
impressive bug-reports source, oh, I should write hundreds of millions
of users, who using Firefox only because of their habits (only because
they are used to firsts FF versions) and who curse every Firefox
crashes, Firefox tardiness, Firefox memory leaks and all new funny
ideas like Firefox tabs groups.
Go to some of your buddys home and see Firefox in action and then ask
yourself, do everything works fine? If everything in Firefox will work
fine, it won't lose its part on the market

Re: Booting to the Web Gervase Markham 7/27/11 11:29 AM
On 27/07/11 07:35, Mike Shaver wrote:
> We have lots of connections to the litl folks (and 2 of our newest
> hires at Mozilla came from litl), but I don't think their stuff is
> quite what you think it is.  They boot into a Clutter-based/GNOME UI,
> and have a separate browser (based on XULRunner).

OK - clearly I misread their marketing! Thanks for the clarification :-)

Gerv


Re: Booting to the Web ya knygar 7/27/11 1:18 PM
>Go to some of your buddys home and see Firefox in action and then ask
> yourself, do everything works fine?

I could confirm - across the years of my personal use and use among
people i know -
there wasn't a moment with Firefox that - everything is just fine, but
it was(is!) the same
for Opera/IE+addons/Chrome :)

You see - not a perfect world,
but Firefox was, obviously, the strongest and most consistent browser
on mass market.

Could you say it's rendering accuracy - fails to you or your buddies?
I don't. It's among best. Pages were written for it in dark Netscape ages.
Could you say its design frustrate you every-time?
I don't. I see - it plays far better in this terms - than average OS.
Could you say it lags?
Yes!
It was lagging behind Opera on my 40Mhz machine, it is lagging behind Chromium
on my 3Ghz.. so? It is consistent experience!)

What i see - mobile Mozilla and this OS will particularly do - make
available some small and !fast geckos, firefoxys, whatever..
Solving these problems bit by bit would bring the speed to finest
rendering and given that I like to customize
my browser.. and Mozilla - always was, is and hopefully will be the
most customizable.

Why there aren't a much better alternatives, given all the money and
other resources
of wealthiest corporations of this world? - is the question to absorb
the reality of current consumer computing
and its software.
Not that - "Why it is so bad with us?"  could easily help.


There are not a lot of useful  browsers, am i right? Maybe even less than OS's.

Particularly - One independent (self-dependent) Open Source Web
provider - Mozilla,
you could argue? It's a pretty authoritarian Open Source Community, so what?


That's the coolest reality with Mozilla and OSS communities - they
evolve, experiment freely in all directions
and inventing some solutions to current gen from time to time. And you
could fork it and became the CEO of
your own Megazilla if you can do better.


Now is a time of rapid changes in web >> browsers, Mozilla is bravely
going with these changes, Now - experience won't and can't be
consistent,
anyway, so what? There are such a  boosts - from time to time,
everybody who have lived  with computers for a 10 years or another 10
years - lived through
more disrespect to habits than - even this project will introduce, and
it's good and it's like it should be in evolution, i think.

 This is, clearly, the project where some solutions will come to light
and new propositions could evolve into reality,
so - i don't see any constrains, among many pro's, especially if you
care about Firefox or FLOSS in general.

Re: Booting to the Web bob_so...@yahoo.com 7/27/11 2:44 PM
On Jul 25, 9:04 pm, Wan Li <wanli...@gmail.com> wrote:

> XUL should not be considered. Chromeless works just fine.

Forgive me, but I think that is an extremely narrow-minded thing to
say.

Consider the iPhone.  One of the reasons why so many people like it is
because the Apps *look good*.  The iPhone Apps have real UI's and
don't look like web pages.  XUL was developed to build UI's, as seen
in Firefox and Thunderbird.  HTML (as used in Chromeless) was
developed to markup web pages. There is a huge difference in the feel
and quality of a UI developed with XUL and one developed with HTML.
An App written in XUL looks and feels much more like a native App.

There may be some doubt about XUL, because it hasn't been used much to
build desktop Apps.  I think it would be different in the mobile
space. Once mobile App developers come to appreciate the elegance and
rapid development time afforded by XUL, they will take to it quickly.
The Apps they develop will look "native", as on the iPhone. The ease
of development and native look could make B2G something unique,
something special.  Otherwise, you're left with is just another
platform for Web Apps, which we already have. Finally, we have XUL
now, so let's leverage it!

Bob

Re: Booting to the Web Sonny Piers 7/27/11 3:31 PM
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.

For the record: http://www.osnews.com/story/24995/NVIDIA_Releases_MeeGo-compatible_Video_Drivers_for_Tegra

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

Re: Booting to the Web ya knygar 7/28/11 3:32 AM
> For the record: http://www.osnews.com/story/24995/NVIDIA_Releases_MeeGo-compatible_Video_Drivers_for_Tegra
Yes, that's the bespoken politics of NVidia, and i don't understand -
where was the MeeGo/Maemo community
in this case - as they should know the advantages, maybe they are just
angry about Android chosen =)

> There is a huge difference in the feel
> and quality of a UI developed with XUL and one developed with HTML.

I disagree,
if developers would use XUL - B2G would be just a platform with XUL Apps,
not Web Apps stack like people are used to with Titanium, PhoneGap, etc. etc.
not - what Chromeless finally promised. And that would be a step backwards.


> There is a huge difference in the feel
> and quality of a UI developed with XUL and one developed with HTML.
Don't forget CSS

> The ease
> of development and native look could make B2G something unique,
> something special.

Given the all the mentioned above, it would be unique only in some *strange*
case of apps per platform, given that  XUL is a XULRunner - not
WebKit, not etc.
Huge step backwards.

> The Apps they develop will look "native", as on the iPhone.


That's already being done for !multiplatform - think about - 6-8(+) platforms
stand-alone web apps by these frameworks. XUL won't make it for Web into
Blackberry, iOS etc. in a reasonable time, if ever.

> Otherwise, you're left with is just another
> platform for Web Apps, which we already have.

That's why i propose to continue Chromeless work, combined with Moz
Open Web Apps,
combined with other intentions - to let the Apps - be GUI - that would
be a huge step forward,
i could bet.
I'll explain:


I see the point in B2G while the Web Apps are Kings in it,
but these Apps could ran in Any modern browser,
but without these goods of integration, maybe,
that would boost the industry and compete with paid markets, for sure.
There will be forks that would spread the idea and there would be a work
for other "web engines" sooner or later.


THE point - i see - is in making an OS from W3C and other acknowledged "groups"
work - maybe (even :) making the Web Video Phone platform and compete with..

as they(groups) have the material for it now, while making this OS real could
just help to refine the existent.


In a different way:

I, don't see a point in making another Chrome OS from B2G,
   for this - Webian OS and forks is enough ;)

But - in making the next step and show that is possible on bleeding age,
making the step on the way that only Mozilla could easily approach, with all
its professionals and gurus.

Well - if not - it's just someone else would show it with your work,
and some amount of your work could be a waste.
Well - maybe not - if first steps are with back-end and to the time of UI-UX
there would be a forks - showing the possibilities.


PS: It's a particular and amazing strength when you could have
something like Chromeless
from your platform - made by 1 man in a spare time (yes, i know it's
history, but anyway),
 i wonder if we'll see any time soon - something like this on WebKit.

Re: Booting to the Web Robert Kaiser 7/28/11 6:15 AM
ya knygar schrieb:

>> There is a huge difference in the feel
>> and quality of a UI developed with XUL and one developed with HTML.
>
> I disagree,
> if developers would use XUL - B2G would be just a platform with XUL Apps,
> not Web Apps stack like people are used to with Titanium, PhoneGap, etc. etc.
> not - what Chromeless finally promised. And that would be a step backwards.

Well, I agree that right now, the quality of XUL UI is way better than
anything you can do in HTML at this time. But I also agree that we
should not use XUL here, despite that - we should work on improving HTML
to a point where it can match XUL UI capabilities instead.

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! :)

Re: Booting to the Web Jonathan Harris 7/28/11 7:26 AM
On 25/07/2011 18:27, 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.

There's a potential (non-technical) risk in using any subset of Android as
the base. According to analysis of contracts between OEMs and Google that
have been disclosed in the Skyhook case
http://thisismynext.com/2011/05/12/google-android-skyhook-lawsuit-motorola-samsung/
:

> Samsung�s agreement also requires that the company only distribute
> Google-approved Android hardware and only distribute software on
> Google-approved devices. We don�t know if Samsung�s current agreement
> includes a similar clause, but those whispers of Samsung building
> Amazon�s rumored tablet are certainly implicated if it does.

i.e. Potential OEMs who may be interested in shipping B2G devices may be
precluded from doing so due to contracts with Google governing their use of
Android-derived code. This issue could be avoided if you used another
platform (e.g. Linaro, MeeGo etc) as the base.

Jonathan.

Re: Booting to the Web Mike Shaver 7/28/11 7:36 AM
On Thu, Jul 28, 2011 at 10:26 AM, Jonathan Harris <jh...@spamcop.net> wrote:
> There's a potential (non-technical) risk in using any subset of Android as
> the base.

There is always potential risk if you're writing software today,
sadly.  Other choices would have different risks (or some of the same,
if they provide the same capabilities -- maybe there's an analysis of
how Meego and Linaro provide the location services somewhere).

We intend to have as little dependency on the Android kernel as
possible, and if needed we can switch OS substrate.  Speculation about
patent stuff consumes a lot of energy, and tends to not be very useful
(I have been neck-deep in the video codec version of this FUDdy space
for a long time).

Mike

Re: Booting to the Web Jonathan Harris 7/28/11 7:47 AM
On 28/07/2011 15:36, Mike Shaver wrote:
> There is always potential risk if you're writing software today, sadly.

True enough.

> Speculation about patent stuff consumes a lot of energy, and tends to not
> be very useful

Note that this isn't a patent issue (which is a whole other can of worms)
but a potential contractual issue. I would suggest some outreach to
potential OEMs if you haven't already done so.

Joanthan.

Re: Booting to the Web Mike Shaver 7/28/11 7:50 AM
On Thu, Jul 28, 2011 at 10:47 AM, Jonathan Harris <jh...@spamcop.net> wrote:
> Note that this isn't a patent issue (which is a whole other can of worms)
> but a potential contractual issue. I would suggest some outreach to
> potential OEMs if you haven't already done so.

I think it's extremely unlikely that using an open source Android
kernel by itself, f.e., would be subject to any such contractual
issues.  That would be tantamount to ruling out all Linux-kernel-based
systems, and Samsung (the article's exemplar) has one of those itself
that's independent of Android (SLP).

Mike

Re: Booting to the Web Sonny Piers 7/28/11 8:11 AM
On 07/28/2011 03:15 PM, Robert Kaiser wrote:
> Well, I agree that right now, the quality of XUL UI is way better than
> anything you can do in HTML at this time. But I also agree that we
> should not use XUL here, despite that - we should work on improving HTML
> to a point where it can match XUL UI capabilities instead.
>
> Robert Kaiser
>

What currently makes XUL cooler than HTML is XBL. In my option we (as
webapp developers) definitively need cross-browser XBL. Or eventually a
simpler XBL-like technology:
http://www.w3.org/wiki/HTML/next#.22behaviors.22 ?

Cheers.

Re: Booting to the Web ya knygar 7/28/11 8:11 AM
> i.e. Potential OEMs who may be interested in shipping B2G devices may be precluded from doing so due to contracts with Google governing their use of > Android-derived code. This issue could be avoided if you used another platform (e.g. Linaro, MeeGo etc) as the base.

I could think of benefits - where OEMs are shipping B2G because of
it's "just" an Android X)


>Speculation about
> patent stuff consumes a lot of energy, and tends to not be very useful

That's the actual case, not a bit of speculations, just a business
relations  - if you want to sell some hardware,
you have to choose, i have told about such a situation in other words - before.

> I think it's extremely unlikely that using an open source Android
> kernel by itself

what do you mean by Android kernel?
 You mean - the kernel derived from Linux kernel,
that is GPL2 - seems like no-one won't need the Google's
approval, but if combined with other "drivers", i think - it's better
to think twice for a corporation like Mozilla.

Re: Booting to the Web Robert Kaiser 7/28/11 9:57 AM
Jonathan Harris schrieb:

> There's a potential (non-technical) risk in using any subset of Android
> as the base.

As there are no plans yet on shipping a real "product" in consumer
terms, I think such fears are premature at this time.
For now, this is an experimental project, and it will not be dependent
too strongly on the lower-level OS base anyhow, so if we ever come to
the conclusion to ship an actual consumer-grade product on this, the
point to voice and think about those concerns will be then but not right
now. Right now the focus needs to be on getting something to work on a
stable base that exists and works today.

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! :)

Re: Booting to the Web Robert Kaiser 7/28/11 9:58 AM
Sonny Piers schrieb:

> What currently makes XUL cooler than HTML is XBL.

AFAIK, XBL2 is in the process of being standardized and works with HTML
(apart from other improvements from, lessons we have learned from
current XBL).

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! :)

Re: Booting to the Web Simon Horton 7/28/11 11:25 AM
I love the idea of making more API's available to the browser and
aiming to be able to support a mobile device platform. I think there
is a lot of benefit and good side effects from this project.

It is worth looking at http://xpud.org/ also an instant on style os
with firefox front end and minimal kernel / drivers to get you up and
running.

Another platform I love is http://tinycorelinux.com/  Linux 2.6 kernel
10 MB install (or just 6 MB for a micro core), has a massive amount of
standard packages you can install and it runs in memory. This would
give you a very stable platform so you can focus on the firefox API's
rather than lots of driver bugs and problems.

/Simon

Re: Booting to the Web ya knygar 7/28/11 12:42 PM
> It is worth looking at http://xpud.org/ also an instant on style os
> with firefox front end and minimal kernel / drivers to get you up and
> running.

its a 3rd time mentioned,
maybe someone would create a separate topic,
found the developers (as i see - last work was in 2010)
and say them - how innovative it was?

> is http://tinycorelinux.com/

i have looked into the project before posting on OS B2G topic,
there are some projects for which there aren't a contact email :)

i think - it worth a creation of separate site with a voting system for
proposed OS back-end - -  Mozilla?

Re: Booting to the Web Mike Shaver 7/28/11 12:47 PM
On Thu, Jul 28, 2011 at 3:42 PM, ya knygar <kny...@gmail.com> wrote:
> i think - it worth a creation of separate site with a voting system for
> proposed OS back-end - -  Mozilla?

No.

Mike

Re: Booting to the Web Nicholas Nethercote 7/28/11 5:11 PM

Then how can you call the B2G project a democracy?!

Oh wait, you didn't.

Nick

Re: Booting to the Web Lawrence 7/28/11 9:31 PM
> 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 really like the general direction. Is the current thinking that this
project will enable Web applications to have the same capabilities as
native applications on mobile OSes like Android or is it to build a
complete replacement Web based OS that runs on top of (or instead of)
existing mobile OSes?

Lawrence

Re: Booting to the Web Chris Jones 7/28/11 10:15 PM
On 07/28/2011 09:31 PM, Lawrence 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.

Both.

Cheers,
Chris

>
> Lawrence

Status of XBL2 (was: Re: Booting to the Web) Henri Sivonen 7/28/11 10:43 PM
On Thu, 2011-07-28 at 18:58 +0200, Robert Kaiser wrote:
> Sonny Piers schrieb:
> > What currently makes XUL cooler than HTML is XBL.
>
> AFAIK, XBL2 is in the process of being standardized and works with HTML
> (apart from other improvements from, lessons we have learned from
> current XBL).

The XBL2 spec has been waiting for implementation for years. The other
browser vendors have waited for Mozilla to implement it first. Now the
action has shifted to the Chrome team wanting to do something simpler,
so a possible outcome is that Chrome ships something other than XBL2 and
XBL2 gets abandoned.

(Hixie, the editor of the XBL2 spec, said a few days ago: "XBL2 is
another example, where despite years of work, it's clear the spec isn't
going anywhere, and we're going to have to make radical changes or
discard it entirely and replace it with something else.")

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

Re: Booting to the Web Dinusha amerasinghe 7/28/11 11:03 PM
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

Hi,

Im from the web development background and im currently a Graduate
Student in Computer Science. Is there any part that i can contribute
to? As for ideas, since there is already a mobile firefox version is
it possible to cutomize/modify it to run as the launcher without any
unnecessary OS components, so that we can run apps on it. futhermore
we could use HTML 5 or XUL to develop apps, since these could be run
without the internet as the phone dialing, sms etc services needs this
facility. BTW where will the contacts stored? is it in the cloud or in
the ususal SIM or the internal data storage?

Kind Regards
Dinusha

Re: Booting to the Web Chris Jones 7/28/11 11:29 PM
On 07/28/2011 11:03 PM, Dinusha amerasinghe wrote:
> 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
>
> Hi,
>
> Im from the web development background and im currently a Graduate
> Student in Computer Science. Is there any part that i can contribute
> to? As for ideas, since there is already a mobile firefox version is
> it possible to cutomize/modify it to run as the launcher without any
> unnecessary OS components, so that we can run apps on it. futhermore
> we could use HTML 5 or XUL to develop apps, since these could be run
> without the internet as the phone dialing, sms etc services needs this
> facility.

https://wiki.mozilla.org/B2G#Contributing is a good place to start.


> BTW where will the contacts stored? is it in the cloud or in
> the ususal SIM or the internal data storage?

It's not entirely clear yet, and the answer will probably be different
for Firefox-on-existing-mobile-OS's and B2G.
https://bugzilla.mozilla.org/show_bug.cgi?id=674720 is where the initial
discussion around that is happening.

Cheers,
Chris

>
> Kind Regards
> Dinusha

Re : Booting to the Web keegybab 7/29/11 1:48 AM
Nice idea, I'm learning. I'll help you soon:-)
Re: Booting to the Web Natanael L 7/29/11 2:34 AM
On Jul 27, 3:12 pm, Robert Kaiser <ka...@kairo.at> wrote:
> Natanael L schrieb:
>
> > Indeed, we could have very exiting UI:s! Mozilla OS should REALLY be
> > split up in modules, the platform and the interface should be
> > separated. Integration between the two should be done with API:s that
> > ANY app can use.
>
> I don't think there's any plan on OS UI for B2G yet, the focus is mostly
> on getting the needed web standards up so web apps can do everything
> that "native" apps can. Everything else is probably an afterthought
> right now, but surely something where contributions are welcome.
>
> > Then things differ: Where Ubuntu use X (soon Wayland?) and GNU
> > software, there will be Chromeless on Mozilla OS.
>
> Wrong. Chromeless is not a graphics environment, it still needs
> something like X or Wayland or whatever in between, AFAIK.
>
> > Where Ubuntu use Gnome, there will be the Mozilla OS interface, built
> > in HTML+JS.
>
> Probably, but I don't think there are any plans on how that is
> structured or laid out. Also, for a tablet OS, not very much is needed
> at that level - the less, the better, in the end.

Well, I'm thinking a bit more high-level then you thought I were, I
guess.
I'm just throwing out ideas that I think will be useful for this
project at some point in time.
I'm thinking it's better to get the ideas out early then late.

Re: Booting to the Web Gen Kanai 7/29/11 2:38 AM

On 7/28/11 2:24 AM, A Pro wrote:
> On 27 Lip, 15:34, Robert Kaiser <ka...@kairo.at> wrote:
>> A Pro schrieb:
>>
>>> If OS will be like new Firefox, you have 100% chance of fail.
>> Right, if it's as successful as current Firefox, it will only have a few
>> hundreds of millions of users, surely too little to claim that anything
>> there works or was a good move. Thanks for reminding us.
>> We should abandon this just like we did abandon Firefox and openness,
>> innovation and opportunity on the web in general.
> Yeah, great example, Robert. "Hundreds of millions of users" is very
> impressive bug-reports source, oh, I should write hundreds of millions
> of users, who using Firefox only because of their habits (only because
> they are used to firsts FF versions) and who curse every Firefox
> crashes, Firefox tardiness, Firefox memory leaks and all new funny
> ideas like Firefox tabs groups.


> Go to some of your buddys home and see Firefox in action and then ask
> yourself, do everything works fine? If everything in Firefox will work
> fine, it won't lose its part on the market
If you are trying to influence the direction of a Mozilla project by denigrating Mozilla software and the people who make it, please don't expect anyone here to listen to your opinions.

--
Gen Kanai

Re: Booting to the Web Natanael L 7/29/11 2:48 AM
On Jul 27, 7:24 pm, A Pro <bat...@gmail.com> wrote:
> On 27 Lip, 15:34, Robert Kaiser <ka...@kairo.at> wrote:
>
> > A Pro schrieb:
>
> > > If OS will be like new Firefox, you have 100% chance of fail.
>
> > Right, if it's as successful as current Firefox, it will only have a few
> > hundreds of millions of users, surely too little to claim that anything
> > there works or was a good move. Thanks for reminding us.
> > We should abandon this just like we did abandon Firefox and openness,
> > innovation and opportunity on the web in general.
>
> Yeah, great example, Robert. "Hundreds of millions of users" is very
> impressive bug-reports source, oh, I should write hundreds of millions
> of users, who using Firefox only because of their habits (only because
> they are used to firsts FF versions) and who curse every Firefox
> crashes, Firefox tardiness, Firefox memory leaks and all new funny
> ideas like Firefox tabs groups.
> Go to some of your buddys home and see Firefox in action and then ask
> yourself, do everything works fine? If everything in Firefox will work
> fine, it won't lose its part on the market

How many addons have they installed and uninstalled over the years?
How many tweaks have they made? Have they kept the same profile all
the time?
Yes, that should preferably not have a negative impact on Firefox, but
it is inevitable that it will since Mozilla can't control the quality
of all addons and the results of all tweaks.
If those were fresh Firefox profiles making a mess on a fresh computer
with high quality drivers (I'm thinking about graphics drivers,
mostly), then that's Mozilla's fault. If not, don't complain to
Mozilla.

Re: Booting to the Web Robert Kaiser 7/29/11 8:29 AM
Dinusha amerasinghe schrieb:

> futhermore
> we could use HTML 5 or XUL to develop apps

Try to not use XUL but instead try to improve HTML with those things it
lacks compared to XUL. If we get those or something similar to initial
HTML implementations and running through the standardization processes,
everyone on the web wins, and that should be the target.
XUL is tempting as it's pretty mature for UI design compared to HTML,
but it's not an open standard and we should really work to make HTML as
mature for UI design while still being the major open standard.

> BTW where will the contacts stored? is it in the cloud or in
> the ususal SIM or the internal data storage?

I personally very much hope we will end up with something that stores
locally but syncs securely via the web ("cloud" if you wish to use buzz
words). Privacy and decentralization need to be as core to those
mechanisms as they are to the Mozilla DNA. :)

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! :)

Re: Booting to the Web Robert Kaiser 7/29/11 8:30 AM
Lawrence schrieb:

Chris has already answered, but I think the emphasis is on the former,
with the latter either being a long-run possible outcome or a vehicle to
achieve the former, whichever you like better. ;-)

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! :)

Re: Booting to the Web Rasmus Wikman 7/29/11 10:23 AM
On Jul 25, 6: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


I've started work on a similar project, called Ubuntu Online.

http://www.ubuntuonline.me

Still in it's infancy and a one man job, but working hard on getting
the prototype fully functional.

In my opinion, the most important part is to first look away from
current dominant technologies (like HTML, JS, and so on) and figure
out what the web will look like in say 5 years from now to avoid
unnecessary programming.

Re: Booting to the Web ya knygar 7/29/11 11:43 AM
> Try to not use XUL but instead try to improve HTML with those things it lacks compared to XUL. If we get those or something similar to initial HTML implementations and running through the standardization processes, everyone on the web wins, and that should be the target.

+1

> Privacy and decentralization need to be as core to those mechanisms as they are to the Mozilla DNA. :)
+1
Could be great if Mozilla would push unhosted.org like ideas to the main-stream

Mozilla had Weave
https://mozillalabs.com/blog/2007/12/introducing-weave/
"provide a basic set of optional Mozilla-hosted online services"

it became Sync but i think - ideas were wilder than this particular
implementation.
The point is in "optional", i am sure - there are people interested and waiting
for a chance to be able to use mobiles  as servers and, even as a distributed
hosting.

> In my opinion, the most important part is to first look away from
> current dominant technologies (like HTML, JS, and so on) and figure
> out what the web will look like in say 5 years from now to avoid
> unnecessary programming.

i think - better to contribute into next JavaScript (Harmony?)
maybe - help the HTML5/CSS3 and, only,  after it - look into
next versions or reinventions,

Maybe - using the standards - better to inspire the use and  creation
as modulated "products" as possible,
so it would be easier to add/replace in particular places.

In my opinion - looking into Flash case for example - everything is
possible - standardized
or not - if there are easy tools to create it for non-experienced
user. So - better to
contribute to the creation of this tools, and after it we would see if
the existing stack
isn't enough or too hard or too old-fashioned.

Re: Status of XBL2 (was: Re: Booting to the Web) Ehsan Akhgari 7/29/11 3:02 PM
On Fri, Jul 29, 2011 at 1:43 AM, Henri Sivonen <hsiv...@iki.fi> wrote:

> On Thu, 2011-07-28 at 18:58 +0200, Robert Kaiser wrote:
> > Sonny Piers schrieb:
> > > What currently makes XUL cooler than HTML is XBL.
> >
> > AFAIK, XBL2 is in the process of being standardized and works with HTML
> > (apart from other improvements from, lessons we have learned from
> > current XBL).
>
> The XBL2 spec has been waiting for implementation for years. The other
> browser vendors have waited for Mozilla to implement it first. Now the
> action has shifted to the Chrome team wanting to do something simpler,
> so a possible outcome is that Chrome ships something other than XBL2 and
> XBL2 gets abandoned.
>

This got me curious.  Do you have any information on what the alternative
that the Chrome team is working on is?

--
Ehsan
<http://ehsanakhgari.org/>

Re: Status of XBL2 (was: Re: Booting to the Web) Mike Hommey 7/29/11 3:23 PM

It looks like people from Google have been working on XBL2 not so long
time ago...
https://bugs.webkit.org/show_bug.cgi?id=52962 and dependencies.

Did they change plans in the meantime ?

Mike

Re: Booting to the Web Matt Vanamburg 7/29/11 7:31 PM
On Jul 25, 11:49 am, 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

With mobile phone processors evolving at a MUCH faster speed than
desktops nowadays, it seems only logical to assume that the mobile
phone/tablet will largely replace the PC for most people very soon,
with docking stations for a larger screen, charging, and faster
processing (Dock integrated with a GPU). Mozilla should develop this
operating system with THIS future in mind. I would be very glad to
answer any questions about my statements if someone wishes me to
elaborate.

Re: Status of XBL2 Cameron McCormack 7/29/11 11:30 PM
On 29/07/11 3:02 PM, Ehsan Akhgari wrote:
> This got me curious.  Do you have any information on what the alternative
> that the Chrome team is working on is?

Here are some wiki pages with notes on what Dmitri Glazkov is doing with
his XBL-like proposal:

http://wiki.whatwg.org/wiki/Component_Model_Use_Cases
http://wiki.whatwg.org/wiki/Component_Model_Brainstorming
http://wiki.whatwg.org/wiki/Component_Model_Constraints
http://wiki.whatwg.org/wiki/Component_Model
http://wiki.whatwg.org/wiki/Behavior_Attachment

And there are the beginnings of a spec:

https://github.com/dglazkov/component-model

and the two sections of that have some text in them are:

http://dglazkov.github.com/component-model/dom.html
http://dglazkov.github.com/component-model/events.html

Re: Booting to the Web ya knygar 7/30/11 3:08 AM
> With mobile phone processors evolving at a MUCH faster speed than
> desktops nowadays, it seems only logical to assume that the mobile
> phone/tablet will largely replace the PC for most people very soon,
> with docking stations for a larger screen, charging, and faster
> processing (Dock integrated with a GPU)

i think it would be very much like you'v described.


 Talking about such a mini PC's with all embedded,
(like this http://trimslice.com/web/ - from Tegra 2 MeeGo article)
we'll, probably, end in possible future of a  not-PC like systems,
because  users won't change the parts in these soon like they can now
-  on PC's.
Of course PC's will remain, but, probably, just like portable devices
dominate the PC market from outside,
these small-tops would dominate inside.


Look at Win8 - it has a "pro" look for Office-like programs  and a
"user-friendly",
"html5" customizable with voice control - for other usage,
that user-friendly  could be a B2G and that "work" - could easily be
with some Linux distro goods.

we'll, probably, see that using something like Debian based distro
combined with B2G could end into collaboration
with Canonical, why not? Mozilla could teach Canonical - how to make
the open-sourced Cloud =)

Canonical would, anyway, lead the "main" Ubuntu users  to mobile
devices(tablets at least) also -
see the touch-friendly Unity GUI, support for ARM's, their "hidden"
mobile initiative.
It brings the Firefox out-of the box now, it doesn't have the
Mozilla's 200mil but,
maybe, only 15mil.
Usage statistic, you know, changing rapidly -- it isn't the goal to pursue.
Canonical is a player now - in pre-installation on actual users
hardware, and B2G could be,
with Ubuntu.

The situation i see is - started with this project Mozilla would have
to expand to tablet OS,
touch OS, that kind of next-OS market you could see - Win, Mac and
Ubuntu is approaching now,
or someone else would easily reuse the B2G for it, without Mozilla
branding -- why to loose the opportunity?

I understand that high-land of Mozilla corporation know it all but,
another notice won't harm, i hope.

It's a great chance for Mozilla to help Linux and vise versa, now -
for the openness of not only Web.

Again -
as i know - correct me if i'm wrong - tendency on the West market is
that majority of users
aren't messing with customizing insides of their PC's, but -
buying a pre-configured models among Model Range from large
"configurators", instead.
You know - the biggest problem would be that these small systems would
be pre-installed
and - i don't afraid for my local markets, but on West - many
 (if not majority, thanks to bitten company)
 devices would be (i could bet) *firmwared* with
particular OS's and that could be hard to change for end-users.

Re: Booting to the Web Neil Harris 7/30/11 4:52 AM
On 30/07/11 11:08, ya knygar wrote:
>> With mobile phone processors evolving at a MUCH faster speed than
>> desktops nowadays, it seems only logical to assume that the mobile
>> phone/tablet will largely replace the PC for most people very soon,
>> with docking stations for a larger screen, charging, and faster
>> processing (Dock integrated with a GPU)
> i think it would be very much like you'v described.
>
>
>   Talking about such a mini PC's with all embedded,
> (like this http://trimslice.com/web/ - from Tegra 2 MeeGo article)
> we'll, probably, end in possible future of a  not-PC like systems,
> because  users won't change the parts in these soon like they can now
> -  on PC's.
> Of course PC's will remain, but, probably, just like portable devices
> dominate the PC market from outside,
> these small-tops would dominate inside.
>

I'm not sure small-tops as separate devices are going to become a
mass-market product. Instead, I think that given the small size and low
component count of that device, and the lack of any need for a fan to
cool it, the next logical thing to do would be to merge the not-PC
circuitry right into the monitor's control PCB, eliminating the need for
a separate case, power supply, connecting cables, sockets and
connectors, and the need for a separate embedded CPU to control the
monitor.

At that point the monitor _is_ the PC, in an iMac-like package, but at a
monitor-like price. Putting it another way, the desktop non-PC would be
equivalent a large tablet on a stand, without the touchscreen, with a
built-in mains power supply, but with the connectors to attach to
external keyboards/mice/trackpads. Given that a TV is just a monitor
with a tuner, as Moore's Law drives CPU/GPU/memory costs down further,
TVs, monitors and not-PCs will all converge to a single product.

There would thus be three standard mass-market devices: phones, tablets,
and all-in-one not-PC/monitors/TVs. Traditional tower PCs would still be
sold but as a specialist high-end product for compute-intensive
workstation applications and PC gaming. I'm not sure what happens to
games consoles.

Given that in this model of the world it is logical for all these
devices to share a single operating system and user interface, and for
the phone and the Web, as the current most familiar and personal
computing experiences, to be the exemplars for this, this makes the
development of B2G very timely.

-- Neil

Re: Booting to the Web ya knygar 7/30/11 6:37 AM
> I'm not sure small-tops as separate devices are going to become a mass-market product. Instead, I think that given the small size and low component count of that device, and the lack of any need for a fan to cool it, the next logical thing to do would be to merge the not-PC circuitry right into the monitor's control PCB, eliminating the need for a separate case, power supply, connecting cables, sockets and connectors, and the need for a separate embedded CPU to control the monitor.

It would be the worst case i could imagine - now
TV brands are just looking into the space of closed TVapps
market, when the hardware, instead of using like an open TiVo box -
with all the connect-able storages, everything you may need..

when this computing hardware would be embedded in majority of TV's
 we would just pay twice for nothing,
i mean
1. for little computer that, otherwise could be used separately with
monitor like a surfing machine, also.
2. for market of proprietary tv apps.

> this makes the development of B2G very timely.

:) yes but - remember - Samsung, just for an illustrative example,
(https://secure.wikimedia.org/wikipedia/en/wiki/Smart_TV)
would, far more likely, use it's own closed Bada or, even, Android for
these needs
(http://www.wired.com/gadgetlab/2010/09/android-holds-the-key-to-samsungs-smart-tv-plans/
http://www.engadget.com/2011/05/10/google-tv-getting-android-3-1-and-market-this-summer-sony-vizi/)

, other brands
also have their contracts now, maybe  ..with you know what.., already.

Note that this Android 3.1(closed source proprietary system)
while(still) in a de-coupled  box variant -
 is the system - B2G (or every small linux with latest, lightly
customized gecko build) could easily compete with
(even with today's "HTML5" apps market),

 instead of supporting while using outdated Android as a back-end.

(There are already the whole bunch of embeddable Linux's and some distro's
https://meego.com/devices/smart-tv -- no, it isn't  another
"advocacy", just a fact)


In some cases it would be Opera engine's
in other something else.. There would be a small number among these big brands
that could be brave enough to use something so MPL'd and GPL'd, i'm afraid.

Having a monitor with a computer inside - not a big deal now - when
you could have such a small computer,
see - these Apple monitor-computers was cool in time where the
smallest comparable "de-coupled"
computer was in size and weight of old HTPC, i mean - MicroATX
motherboards all this "usual" staff,
pretty weighty with a pretty standard PC components.

..passive knowledge won't stop TV brands from expansion, of course =)

So - with the current position of project  -  there won't be many TV
with B2G, but there a chance for many small boxes that could be
connected to TV,
TFT, etc. -  that's my opinion.
-


Finally -
we'll all end in totally embedded environment with every fringe having
the full-powered PC but some closed,
with closed Apps market  and  completely un-useful for advanced use
"systems", that's where your
(places where's the Mozilla office's now) market is approaching.

OR - we'll buy these little-pc's separately of TV's
and fringes, install some open OS there, use it with open app markets
like Open Web Apps propose, for example,
and wait for the corps contracts to end; until -  buy these TV's
without a closed markets embedded,
 buy these slate little pc's on saved money and use them with Open Web
Platform intensively and,

in this case:

finally - Open Web Platform is what
these brands would likely to use instead of DRM (see -
http://www.defectivebydesign.org/),
just because - people would be used to these Open Web Markets and
non-DRM'd streams
from open internet... I think - Mozilla is automatically against DRM -
while supporting all the
latest open web initiatives.

--
In Russia there are very nice example  of ivi.ru and other-like
platforms that are transforming "lazy piracy"
into something profit-able by ads, instead of that - you could see
in.. many western DRM'd platforms with some renting,
along(!) with showing the ads.

Re: Booting to the Web Mike Hommey 7/30/11 6:44 AM
On Sat, Jul 30, 2011 at 12:52:58PM +0100, Neil Harris wrote:
> At that point the monitor _is_ the PC, in an iMac-like package, but
> at a monitor-like price. Putting it another way, the desktop non-PC
> would be equivalent a large tablet on a stand, without the
> touchscreen,

Some of the new all-in-one desktop computers from at least HP and Sony
come with touchscreens.

> with a built-in mains power supply, but with the
> connectors to attach to external keyboards/mice/trackpads. Given
> that a TV is just a monitor with a tuner,

Recent TVs are actually computers, some of which even run Linux (LG,
iirc)

> as Moore's Law drives
> CPU/GPU/memory costs down further, TVs, monitors and not-PCs will
> all converge to a single product.

Even if they don't converge, TVs are more and more becoming computers
and a window to the web. Something like B2G could be exactly what they
need.

Mike

Re: Booting to the Web Neil Harris 7/30/11 7:10 AM
On 30/07/11 14:37, ya knygar wrote:
>> I'm not sure small-tops as separate devices are going to become a mass-market product. Instead, I think that given the small size and low component count of that device, and the lack of any need for a fan to cool it, the next logical thing to do would be to merge the not-PC circuitry right into the monitor's control PCB, eliminating the need for a separate case, power supply, connecting cables, sockets and connectors, and the need for a separate embedded CPU to control the monitor.
> It would be the worst case i could imagine - now
> TV brands are just looking into the space of closed TVapps
> market, when the hardware, instead of using like an open TiVo box -
> with all the connect-able storages, everything you may need..
>
> when this computing hardware would be embedded in majority of TV's
>   we would just pay twice for nothing,
> i mean
> 1. for little computer that, otherwise could be used separately with
> monitor like a surfing machine, also.
> 2. for market of proprietary tv apps.
>

I agree, a world of closed DRM'd TV-OS television-computers would be a
nightmare.

I wasn't advocating it -- I was just predicting the likelihood of this
becoming a mainstream form factor for computers, because of the effect
of technological change, in the form of Moore's Law and market forces
(consumer reluctance to have two boxes, instead of a single cheaper box)
acting together.

As with all changes in technology, the opportunity for OS change during
this single-box-computer transition, if it happens, (and it's already
happened in phones and tablets) could be used for both good or ill --
the presence of truly open zero-cost Free Software operating systems for
such devices is likely to be a big factor in deciding which of the two
outcomes will dominate.

In the ideal world, televisions become open computers. In the nightmare
world, computers become televisions.

-- Neil

Re: Booting to the Web Aaron Miller 7/30/11 5:30 PM
Hello all.

I'm fascinated by this project's ambitions, and would love to support
its efforts. That said, there are a few concerns I have as a
developer. I'll first note that most people seem to be hung up on the
whole Android thing and "why another OS?" Those aren't concerns of
mine, since the goal of this OS is to be more open and accessible than
the other OSes. (I for one, would rather develop for one OS and be
able to target multiple OSes at the same time.)

I'm not an HTML5/JS/CSS "developer." I develop in C (not C++). Most of
the development I do is proprietary by contract, and therefore cannot
have any source code made visible. I'm unfamiliar with any existing
technologies that allow for a "JavaScript byte code," although that's
exactly what I'm looking for. Any such technology would be useful if
it were adopted as a standard, but I wouldn't mind utilizing it prior
to that. Are there any oppositions to a so-called "compiled
JavaScript?"

There are multiple benefits to an open standard compiled JavaScript
(CJS?).
 * Smaller page downloads. (Byte code would be shorter. Moot point for
on-device apps, I suppose.)
 * Performance. (Easier to perform just-in-time compilations of the
code. This is important for games and such.)
 * Multiple source languages. (I could technically still use C to
develop my code, and have it target the CJS. I could even develop my
own language, and so on.)
 * Proprietary apps. (Although I'm all for open source, it doesn't
work for many companies that are proprietary-only.)
 * Start-up time. (Because it's already in byte code form, no
compilation process has to occur. It already occurred, thus saving
time.)

The CJS could have all of the capabilities of JS, and still be just as
dynamic if built correctly. There are other issues to tackle as well,
such as actually becoming a standard, but I think it would be a good
idea to actually tackle this. I find that especially true for a new
operating system for mobile devices. (iOS, Android, WP7, etc, all have
the benefit of actually being able to play 3D games in real-time on
low-spec hardware. Even my horrid Palm Pre can play 3D games at a
decent rate, as long as they're native.)

I ask that the Mozilla leaders consider accepting work into the OS, as
well as Firefox, for any form of a CJS if they haven't already. Please
note that I'm not suggesting a compiled HTML5/CSS; only a compiled
JavaScript.

Also, support for OpenCL would be good, as well as a standard byte
code for GLSL-compiled shaders. (Direct3D has a single byte code that
shaders compile to, making it easier to deploy games. I quite like
that feature and the concept carries over here, to JS.)

Cheers,
Aaron

Re: Booting to the Web Boris Zbarsky 7/30/11 7:59 PM
On 7/30/11 8:30 PM, Aaron Miller wrote:
> There are multiple benefits to an open standard compiled JavaScript
> (CJS?).
>   * Smaller page downloads. (Byte code would be shorter. Moot point for
> on-device apps, I suppose.)

Are you sure bytecode would necessarily be shorter than the JS source?

>   * Performance. (Easier to perform just-in-time compilations of the
> code. This is important for games and such.)

Actually, this is not the case.  In particular, fixing a bytecode
precludes certain optimization opportunities; witness the fact that
Spidermonkey has been _changing_ its bytecode to make JIT compilation
easier.

In the end, the exact preferred bytecode form for JIT compilation
depends on the exact design of the compiler and VM; if you fix a
bytecode, chances are implementations would have to decompile it and
then recompile.  Brendan has talked a good bit about this recently.  In
particular, this experiment has been tried before, with Java; at this
point the frozen Java bytecode format is one of the things that actually
gets in the way of fast Java program startup because the JITs basically
have to decompile it and recompile through a totally different IR.

>   * Multiple source languages. (I could technically still use C to
> develop my code, and have it target the CJS. I could even develop my
> own language, and so on.)

You can do this right now, and target JS proper, no?

Or is the concern that compiler-generated JS is somehow "source" while
decompilable bytecode that is equivalent would not be?

>   * Proprietary apps. (Although I'm all for open source, it doesn't
> work for many companies that are proprietary-only.)

I really fail to see the difference between having a compiled
representation that happens to be JS source code and a compiled
representation that can then be used to generate JS source code....

Or put another way, you could just pick a bytecode format, compile your
proprietary app in another language to it, decompile the result to JS
and ship that JS down.

>   * Start-up time. (Because it's already in byte code form, no
> compilation process has to occur. It already occurred, thus saving
> time.)

See above.  Decompiling and recompiling probably takes more time than
just compiling once.

-Boris

Re: Booting to the Web GODAXEN 8/2/11 5:01 AM
On Jul 31, 4:59 am, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 7/30/11 8:30 PM, Aaron Miller wrote:
>
> > There are multiple benefits to an open standard compiled JavaScript
> > (CJS?).
> >   * Smaller page downloads. (Byte code would be shorter. Moot point for
> > on-device apps, I suppose.)
>
> Are you sure bytecode would necessarily be shorter than the JS source?
>
> >   * Performance. (Easier to perform just-in-time compilations of the
> > code. This is important for games and such.)
>
> Actually, this is not the case.  In particular, fixing a bytecode
> precludes certain optimization opportunities; witness the fact that
> Spidermonkey has been _changing_ its bytecode to make JIT compilation
> easier.
>
> In the end, the exact preferred bytecode form for JIT compilation
> depends on the exact design of the compiler and VM; if you fix a
> bytecode, chances are implementations would have to decompile it and
> then recompile.  Brendan has talked a good bit about this recently.  In
> particular, this experiment has been tried before, with Java; at this
> point the frozen Java bytecode format is one of the things that actually
> gets in the way of fast Java program startup because the JITs basically
> have to decompile it and recompile through a totally different IR.

Not a true byteocde, but a bytecode-like compression scheme with a
partial fixed dictionary with the possibility to be executed without
full decompressing it, can be interesting.

Re: Booting to the Web Aaron Miller 8/3/11 3:11 AM
On Jul 30, 9:59 pm, Boris Zbarsky <bzbar...@mit.edu> wrote:
> On 7/30/11 8:30 PM, Aaron Miller wrote:
>
> > There are multiple benefits to an open standard compiled JavaScript
> > (CJS?).
> >   * Smaller page downloads. (Byte code would be shorter. Moot point for
> > on-device apps, I suppose.)
>
> Are you sure bytecode would necessarily be shorter than the JS source?

If done properly the byte code could be significantly shorter than the
JS source. String duplicates, floating point values, variable names,
etc... could be referenced via an index where as a table could exist
at the end of all of that. As an ultra simple example, imagine "a =
b*c + d/e." The byte code for the algorithm (ignoring the variables)
could be implemented along the lines of:

 muls %r0, b, c // dst, x, y
 divs %r1, d, e // dst, x, y
 add %r0, %r0, %r1 // dst, x, y
 store a, %r0 // dst, src

Each opcode would could be one byte in size (I found that six to seven
bits would also be sufficient as well). The following "tokens" (the
arguments) could vary in size. Variables could be referenced by index
(same for temporary registers). The three operand form above could
have several variations. Only five bits would be necessary for thirty-
two temporary registers (r0 through r31). If a single restriction is
placed (such that each instruction can only reference up to two
variables), then you can potentially decrease the size of each
instruction.

>
> >   * Performance. (Easier to perform just-in-time compilations of the
> > code. This is important for games and such.)
>
> Actually, this is not the case.  In particular, fixing a bytecode
> precludes certain optimization opportunities; witness the fact that
> Spidermonkey has been _changing_ its bytecode to make JIT compilation
> easier.
>
> In the end, the exact preferred bytecode form for JIT compilation
> depends on the exact design of the compiler and VM; if you fix a
> bytecode, chances are implementations would have to decompile it and
> then recompile.  Brendan has talked a good bit about this recently.  In
> particular, this experiment has been tried before, with Java; at this
> point the frozen Java bytecode format is one of the things that actually
> gets in the way of fast Java program startup because the JITs basically
> have to decompile it and recompile through a totally different IR.
>

Compiling twice (first compiling from byte code to JS, then from JS to
another byte code) is redundant, but easy to implement. If the focus
is on performance, and more importantly on the user, then the harder
path should be taken. I digress though. Multiple versions of the byte
code format could exist, and I'm also not saying that JavaScript
shouldn't exist. I'm merely requesting that one additional form be
supported.

More to the point, the byte code format could take advantage of any
"post optimization" opportunities like the JS would, since it's not
actually in native code. There are certain universal optimizations
(like dead-code removal) that really should be done prior to the JS
being posted. Although things like the closure compiler exist, there
are other optimizations that can be witnessed through byte code. As an
example, taking the dot product of a vector or quaternion (a common
task in 3D rendering)--which you are likely to do when using WebGL--
can be done as follows.

 dot_product = a.x*b.x + a.y*b.y + a.z*b.z; // if quaternion, +
a.w*b.w;

This can be reduced into an vectorized variation (thus taking up less
space in the byte code, as well as being easy to translate to existing
SIMD processors). Multiplying several components at once and adding
the results can be done in a relatively short byte code operation. To
be fair though, this is not something the average web user sees.
(Also, there are more complex operations that exist, like matrix
multiplies, that can be vectorized as well.)

> >   * Multiple source languages. (I could technically still use C to
> > develop my code, and have it target the CJS. I could even develop my
> > own language, and so on.)
>
> You can do this right now, and target JS proper, no?

You're correct, you can. I overlooked source-to-source compilation.

>
> Or is the concern that compiler-generated JS is somehow "source" while
> decompilable bytecode that is equivalent would not be?
>

No, that's not the concern. The idea here was that you could probably
use an existing compiler (like clang, or whatever you like) modify the
LLVM code generator and output to the bytecode format. Alternatively,
if someone has already done the work, they could share it.

> >   * Proprietary apps. (Although I'm all for open source, it doesn't
> > work for many companies that are proprietary-only.)
>
> I really fail to see the difference between having a compiled
> representation that happens to be JS source code and a compiled
> representation that can then be used to generate JS source code....
>
> Or put another way, you could just pick a bytecode format, compile your
> proprietary app in another language to it, decompile the result to JS
> and ship that JS down.
>

The JS source code already has to be converted to a format. Native
processor code is always faster than interpreted byte code. If a
significant number of optimizations occurs on the compilation process
(a luxury the browser might not have) less optimization has to occur
when converting to native code. That said, the browser could choose to
optimize byte code less, saving time.

> >   * Start-up time. (Because it's already in byte code form, no
> > compilation process has to occur. It already occurred, thus saving
> > time.)
>
> See above.  Decompiling and recompiling probably takes more time than
> just compiling once.

Lexical/syntax/semantic analysis plus optimization, term rewriting,
dead code removal and other optimizations followed by code generation
and possibly "peephole optimization" is all very expensive for larger
projects. Offering the end user the best experience possible is
something every company and developer should be concerned about, IMO.
Doing the optimizations once during the development process, instead
of many times per user (ignoring that you could cache the result)
seems ideal to me.

>
> -Boris

I'm fine with the JavaScript, and compiling from one language to
another. Just tossing an idea out there. Thanks for reading!

Cheers,
Aaron

Re: Booting to the Web Boris Zbarsky 8/3/11 6:26 AM
On 8/3/11 6:11 AM, Aaron Miller wrote:
> If done properly the byte code could be significantly shorter than the
> JS source. String duplicates, floating point values, variable names,
> etc... could be referenced via an index where as a table could exist
> at the end of all of that.

If you have lots of duplicated strings, sure.

I'm not saying the bytecode _wouldn't_ be smaller.  Just that it's not
obvious a priori for actual web workloads.

> Compiling twice (first compiling from byte code to JS, then from JS to
> another byte code)

Not all JS engines compile to byte code.  Spidermonkey does, for now,
but V8 for example does not.

But that wasn't the point.  The point is that the bytecode is almost
certainly going to make "optimizations" that then have to be undone to
do proper optimization in the compiler.  You propose some optimizations
like that in your very post (e.g. converting repeated constant string
concatenation to a bunch of "add" bytecodes involves analyzing each
sequence of "add" bytecodes to see whether it's actually string
concatenation of constant strings under the hood and then not actually
treating it as adds; Spidermonkey does that sort of analysis on the AST
when it compiles to bytecode right now).

This is exactly what happens in the Java world right now: javac makes
optimizations when compiling to bytecode that the JIT then has to undo
before it can do its own (much better) optimization analysis.

> If the focus is on performance, and more importantly on the user, then the harder
> path should be taken.

The harder path that gives better performance is what I described.  The
easy path would be to just compile the bytecode to native code and forgo
optimization opportunities in the process.

> Multiple versions of the byte code format could exist

That seems _really_ undesirable.

> I'm merely requesting that one additional form be supported.

All I'm saying is that the costs of such support would be significant,
while the benefits are dubious.  It doesn't seem like a worthwhile
tradeoff for us, from my perspective.

I'm willing to be proved wrong, as always.

> More to the point, the byte code format could take advantage of any
> "post optimization" opportunities like the JS would, since it's not
> actually in native code.

Yes, but it's likely to not be able to take advantage of them as cheaply.

> There are certain universal optimizations (like dead-code removal) that really should be done prior to the JS
> being posted.

You can't really do DCE on JS at compile time, because you have no way
to know whether the code is dead.  If a function is defined, it can be
called.  If the code is reached at all, then chances are it can be
called in a way that causes side effects and therefore must run.  So the
only way to do DCE on actual source is through whole-program (including
browser extensions) analysis, other than trivial cases (like
conditionals on compile-time constants that can't be redefined at
runtime).
http://blog.mozilla.com/rob-sayre/2010/11/17/dead-code-elimination-for-beginners/
used to have a good description of the DCE issues in JS, but seems to be
down no.  :(

> As an example, taking the dot product of a vector or quaternion (a common
> task in 3D rendering)--which you are likely to do when using WebGL--
> can be done as follows.
>
>   dot_product = a.x*b.x + a.y*b.y + a.z*b.z; // if quaternion, +
> a.w*b.w;
>
> This can be reduced into an vectorized variation (thus taking up less
> space in the byte code, as well as being easy to translate to existing
> SIMD processors).

Yes, but the JIT could do this too, right?

And the JIT may well be able to do a better job than the bytecode
compiler can...

I'm not saying this is not a possible win, but it's by no means a
guaranteed win.

> To be fair though, this is not something the average web user sees.

Actually, this is changing with webgl.  There are open bugs on adding
vectorization primitives of some sort to JS on either the JIT or
language level.

> No, that's not the concern. The idea here was that you could probably
> use an existing compiler (like clang, or whatever you like) modify the
> LLVM code generator and output to the bytecode format. Alternatively,
> if someone has already done the work, they could share it.

http://syntensity.blogspot.com/2011/04/emscripten-10.html is post about
an LLVM code generator to generate JS source from LLVM bytecode, in case
you hadn't run into it yet.

> The JS source code already has to be converted to a format.

In the case of some JS engine that "format" is the AST and then native code.

> Native processor code is always faster than interpreted byte code.

Yes.

> If a significant number of optimizations occurs on the compilation process
> (a luxury the browser might not have)

Browsers are moving to multi-level compilers just like the JVM.  At this
point at least V8, Spidermonkey, and Carakan all have dynamic
recompilation of hot code with higher optimization levels.

Bytecode may make such optimizations easier.  Or it might make them
harder (as in the Java case).  It's not a guaranteed win.

>> See above.  Decompiling and recompiling probably takes more time than
>> just compiling once.
>
> Lexical/syntax/semantic analysis plus optimization, term rewriting,
> dead code removal and other optimizations followed by code generation
> and possibly "peephole optimization" is all very expensive for larger
> projects.

Which is why JITs don't compile the whole project at once typically;
they just compile the code you run.

> Offering the end user the best experience possible is
> something every company and developer should be concerned about, IMO.

OK, _that_ we're agreed on.

> Doing the optimizations once during the development process, instead
> of many times per user (ignoring that you could cache the result)
> seems ideal to me.

If they're the right optimizations.

But which ones are "right" depends on the JS engine, while the bytecode,
if one were to be developed, would have to be cross-browser.  Thus with
high probability it would be doing the wrong optimizations some fraction
of the time.

Would it still be a win?  Hard to tell....

-Boris

Re: Booting to the Web v3nom 8/6/11 12:46 PM
Hi,
I am really interested in the idea of mobile web OS, but after contemplating it a bit I have reached a dead end.

First of all, it is not something completely new. A lot of apps on Android platform are just web page wrappers and with mobile frameworks they are getting just better, because it enables communication between hardware and html/js. Phonegap does basically all you want to achieve. Most native apps are also just web service consumers and could have been implemented as web apps if developers would be aware of new technologies. Barely any data is stored only on the phone, so Android could be called cloud OS.

Secondly, have you noticed how terribly slow web apps are on mobile devices. Those developed with frameworks and stored internally are okay, but for example dynamically loaded (even with home Wi-Fi) Gmail is a nightmare.  The only solution I see is to cache/save all web apps to phone’s storage, but then how that’s different from current situation on Android.

Chrome OS for laptops are good idea, because it takes a while to set up a desktop environment. With mobile phones it is a different story. You can easily log on to a new Android phone and all programs will be downloaded and installed for you in few minutes. After that you are ready to browse your old files on dropbox or create documents on GDocs.

Re: Booting to the Web ya knygar 8/7/11 6:55 AM
> Phonegap does basically all you want to achieve.
It uses the given API's of devices, permanently outdated embedded WebKit's,
while this project aims to experiment with and develop new if needed.
To explore the new and outstanding path of user-developed apps as an
OS(GUI..) itself.
 The true WWW OS, not that half-measures on the road.

My point is - people spend with Web Apps - much more time than
with a stand-alone one's, that's the paradigm. By that - Web Apps should
be more important and functional than stand-alone. That, at worst(or
not, for these who don't want JS everywhere)
 - with some plug-ins like NaCL or else -  could lead into really easy
portable if not already interoperable applications.
That, in the order, would lead to (long-time)dream(ed) world of
united, controlled and Open platform for Developers and Users,
not Corporations in the main.


Well - it would lead if other mobile OS's could also support and
implement this idea in some way,
or use some stand-alone derivative from B2G browser, i hope - just a
Mobile Firefox of future.

There would be a "closed"(restricted) for Independent(fully
stand-alone) Web browsers:
platforms like iOS etc. that, probably, won't make it in a this way,
but users of  such a platforms - pay a lot of money to corporation for their OS
 and services, so i think - these would figure something out, sooner or later.

As such, this project is an experiment, awaited by many.
Kind of the Tower of Babel
 if you don't mind the (possibly)offensive "reach the God(s)" context.

You are right that mobile phones are different from other platforms.
I'd say - these are the most important and revealing platform of interest.
The mobile hardware capabilities are enough to start now, so the "problem"
was in native abilities for speed and optimizations, that's another
reason, i think,
of a Mozilla OS, not another XULRunner experiment for capable OS's.

> but for example dynamically loaded (even with home Wi-Fi) Gmail is a nightmare.
i think - that's among goals of this project - to make web apps work
and feel better/faster (not just be "native").
It's logical that with a stand-alone OS instead of framework - you get
all chances to see the best of it.

> Chrome OS for laptops are good idea, because it takes a while to set up a desktop environment.
Mozilla is approaching the obvious unification way so Web would be Web
everywhere, with your bookmarks of apps,
synchronized apps etc. If it won't be done on Open Source tech it
would be, surely, done in CPC(closed proprietary cloud :)

> You can easily log on to a new Android phone and all programs will be downloaded and installed for you in few minutes.

Mozilla is working/would work on the same, as i see. Except of it
would be not Android but Web Apps.

> After that you are ready to browse your old files on dropbox or create documents on GDocs.

CPC!)
I think the time is right for Mozilla OS and to the time of it's
release there would be reliable non-proprietary,
or, at-least, fully controllable
storage for most of this. And there is (an evolving?) Mozilla Sync now.

Re: Booting to the Web Stefan Arentz 8/10/11 9:32 AM

On 2011-07-27, at 5:44 PM, bob_so...@yahoo.com wrote:

> On Jul 25, 9:04 pm, Wan Li <wanli...@gmail.com> wrote:
>
>> XUL should not be considered. Chromeless works just fine.
>
> Forgive me, but I think that is an extremely narrow-minded thing to
> say.
>
> Consider the iPhone.  One of the reasons why so many people like it is
> because the Apps *look good*.  The iPhone Apps have real UI's and
> don't look like web pages.  XUL was developed to build UI's, as seen
> in Firefox and Thunderbird.  HTML (as used in Chromeless) was
> developed to markup web pages. There is a huge difference in the feel
> and quality of a UI developed with XUL and one developed with HTML.
> An App written in XUL looks and feels much more like a native App.

I am not so sure about this. I played with a WebOS phone recently and it looked and 'felt' pretty awesome. Very much like a native apps. And apps on that platform are all .. html based :-)

 S.

Re: Booting to the Web Robert Kaiser 8/10/11 5:22 PM
bob_so...@yahoo.com schrieb:

> An App written in XUL looks and feels much more like a native App.

Right now, yes. But that doesn't mean that we can't make standardized
HTML as fitting for it in the future. That's one of the areas that
should be attacked by this B2G experiment, IMHO.

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! :)

Re: Booting to the Web ya knygar 8/10/11 5:34 PM
> that doesn't mean that we can't make standardized HTML as fitting for it in the future. That's one of the areas that should be attacked by this B2G experiment,

+1

Re: Booting to the Web Matthew Phillips 8/12/11 7:34 AM
I'm interested in developing a Contacts app.  I'm assuming B2G will support the Contacts API[1].  Does Fennec currently?

[1]http://www.w3.org/TR/contacts-api/

Re: Booting to the Web Matt Brubeck 8/12/11 8:30 AM
On 08/12/2011 07:34 AM, Matthew wrote:
> I'm interested in developing a Contacts app.  I'm assuming B2G will support the Contacts API[1].  Does Fennec currently?

No, Fennec does not currently support the Contacts API.

Re: Booting to the Web alsaf 8/21/11 1:02 AM
I've just bought an android phone and I think this project could be a
success if the following can be achieved:

* Increased battery life - goes without saying
* Privacy - I want the freedom to use the phone the way I want and be
comfortable that my personal details being hacked. With open source
software, I am confident that there will be transparency in the way
the OS access private information that I can't get from a company. I
am also confident that any security breaches can be found and fixed
quickly.
* Lack of restrictions - I want the freedom to do what I want with my
phone. An example of why this is not possible with current versions of
android is that my network provider has removed the ability to export
contacts to SD card, forcing me to sync my contacts with their or
another companies service. A free syncing tool doesn't seem to
work.
* Easy configuration of the user interface.

I was also thinking, could this project be used as a way to configure
hardware for specific needs? An example of this could be a company
that needs a scanner for one of their processes. Rather than having to
by an expensive model, they could get a cheap android phone and use
this software so that it just scans barcodes via the phones camera and
transmit it via wifi (obviously the phone features will be disabled so
the modified phone can't be abused).

Re: Booting to the Web ya knygar 8/21/11 6:10 AM
> * Privacy - I want the freedom to use the phone the way I want and be
> comfortable that my personal details being hacked. With open source
> software, I am confident that there will be transparency in the way
> the OS access private information that I can't get from a company. I
> am also confident that any security breaches can be found and fixed
> quickly.

there is a http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-July/002329.html
and http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-August/002371.html
threads,
i think - the best fitting so far is https://guardianproject.info/
Since we would develop the Augmented Reality with B2G,
i think - the part or FBX and theFNF.org would work on particular
editions with advanced features for

> * Increased battery life - goes without saying
> * Lack of restrictions - I want the freedom to do what I want with my
> phone. An example of why this is not possible with current versions of
> android is that my network provider has removed the ability to export
> contacts to SD card, forcing me to sync my contacts with their or
> another companies service. A free syncing tool doesn't seem to
> work.
> * Easy configuration of the user interface.

+1

 since it would be a separate OS, there would be a companies - you could
buy the device from and won't loose your warranty by rooting and other
usual GNU/Linux work.

> I was also thinking, could this project be used as a way to configure
> hardware for specific needs? An example of this could be a company
> that needs a scanner for one of their processes. Rather than having to
> by an expensive model, they could get a cheap android phone and use
> his software so that it just scans barcodes via the phones camera and
> transmit it via wifi (obviously the phone features will be disabled so
> the modified phone can't be abused).

i hope so, i'v seen a reply from Mozilla B2G team member(s) that the OS would
be as de-coupled and customizable as most of us wish.
With Android in the core or with else - i think - embedding B2G into
fridge's environment
should not be hard, even more - making a really embeddable OS would
lead into a real success,
i think. I'v seen some topics about other FLOSS mobile OS's and people
kind of conclude that
- you should be able to change the OS to the needs, at least GUI and
B2G is essentially a GUI,
as i see.

Re: Booting to the Web DGMurdockIII 8/21/11 6:37 AM
you can get the android source from here http://source.android.com/source/index.html
Re: Booting to the Web Robert Kaiser 8/21/11 7:32 AM
DGMurdockIII schrieb:

> you can get the android source from here http://source.android.com/source/index.html

Not for the most current releases, i.e. Honeycomb or Android 3.0 - only
some parts of that are available, but not most or all of it. Android is
only somewhat open, and only when Google is in the mood for it.

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! :)

Re: Booting to the Web alsaf 8/22/11 9:24 AM
ya knygar wrote:

> there is a http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-July/002329.html
> and http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-August/002371.html
> threads,
> i think - the best fitting so far is https://guardianproject.info/
> Since we would develop the Augmented Reality with B2G,
> i think - the part or FBX and theFNF.org would work on particular
> editions with advanced features for

The need for privacy is valid for a number of reasons, whether from a
libertarian standpoint of having the freedom to do what you want as
long as you don't harm anyone, to legal issues in regards as to who
owns your data is copied to a companies server and to concerns about
identify and data theft both from your device and the companies server
that you sync to.

The Guardian project sounds interesting as long as it doesn't add
bloat to your device which consumes unnecessary battery power.


> i hope so, i'v seen a reply from Mozilla B2G team member(s) that the OS would
> be as de-coupled and customizable as most of us wish.
> With Android in the core or with else - i think - embedding B2G into
> fridge's environment
> should not be hard, even more - making a really embeddable OS would
> lead into a real success,
> i think. I'v seen some topics about other FLOSS mobile OS's and people
> kind of conclude that
> - you should be able to change the OS to the needs, at least GUI and
> B2G is essentially a GUI,
> as i see.

I'm sure there are companies who would want to customise phones for
specific uses but there are also manufacturers who would want to
create low price phones that have low hardware specs. Maybe that is
where B2G could get support from commercial manufacturers. There is
definately a market for these devices as witnessed by the Elonex and
CNM subnetbooks:

http://en.wikipedia.org/wiki/Subnotebook

I had forgotten to ask, is the purpose of the B2G project to create a
platform solely consisting of a GUI and apps written in HTML5 or will
it be cloud based where an active network connection is required for
the apps to run?

Re: Booting to the Web alsaf 8/22/11 9:26 AM
ya knygar wrote:

> there is a http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-July/002329.html
> and http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-August/002371.html
> threads,
> i think - the best fitting so far is https://guardianproject.info/
> Since we would develop the Augmented Reality with B2G,
> i think - the part or FBX and theFNF.org would work on particular
> editions with advanced features for

The need for privacy is valid for a number of reasons, whether from a


libertarian standpoint of having the freedom to do what you want as
long as you don't harm anyone, to legal issues in regards as to who
owns your data is copied to a companies server and to concerns about
identify and data theft both from your device and the companies server
that you sync to.

The Guardian project sounds interesting as long as it doesn't add
bloat to your device which consumes unnecessary battery power.


> i hope so, i'v seen a reply from Mozilla B2G team member(s) that the OS would
> be as de-coupled and customizable as most of us wish.
> With Android in the core or with else - i think - embedding B2G into
> fridge's environment
> should not be hard, even more - making a really embeddable OS would
> lead into a real success,
> i think. I'v seen some topics about other FLOSS mobile OS's and people
> kind of conclude that
> - you should be able to change the OS to the needs, at least GUI and
> B2G is essentially a GUI,
> as i see.

I'm sure there are companies who would want to customise phones for


specific uses but there are also manufacturers who would want to
create low price phones that have low hardware specs. Maybe that is
where B2G could get support from commercial manufacturers. There is
definately a market for these devices as witnessed by the Elonex and
CNM subnetbooks:

http://en.wikipedia.org/wiki/Subnotebook

I had forgotten to ask, is the purpose of the B2G project to create a
platform solely consisting of a GUI and apps written in HTML5 or will
it be cloud based where an active network connection is required for
the apps to run?

Also, I've read the F

Re: Booting to the Web Matthew Phillips 8/22/11 5:42 PM
An active connection isn't required because Fennec supports Cache.manifest.  You only need an active internet connection to "install" the app, the same way you would for a native app that you are downloading.  After you've loaded the app once, it will work with or without an internet connection (of course many apps are worthless without an internet connection if they use internet resources, but that's another matter).

For example, I'm working on a phone dialer app. It has no need for internet once all resources are cached.

Re: Booting to the Web alsaf 8/23/11 11:31 AM

Matthew wrote:
> An active connection isn't required because Fennec supports Cache.manifest.  You only need an active internet connection to "install" the app, the same way you would for a native app that you are downloading.  After you've loaded the app once, it will work with or without an internet connection (of course many apps are worthless without an internet connection if they use internet resources, but that's another matter).
>
> For example, I'm working on a phone dialer app. It has no need for internet once all resources are cached.

The reason why I had asked is that on the web, people were saying that
B2G is going to be totally cloud based and would chew up network
traffic. I realised that this was either misinformed or just ignorance
but wanted to make sure.

The reason why I like the like the idea of HTML5 is that it is
probably the closet model of separating GUI and underlying code. The
other reason is that is cross-platform and considering the amount of
development and support it gets, is less buggy than desktop based
Graphical toolkits.

Re: Booting to the Web Julio 8/24/11 2:58 AM
On 25 jul, 13:19, Ian McKellar <ian.mckel...@rd.io> wrote:
> 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

Yes, I can see the useful use of this APIs, my problem in thay I'm not
sure if I must intall in my zone. My legislation more recent is
DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of
13 December 1999 on a Community framework for Electronic Signatures.
And the last version of Flash that I must use is 10.1.0-aih. Can I
receive any support for this questions?

Best Regards

Julio Belinchón Hernández

Re: Booting to the Web Anders Feder 8/25/11 7:00 PM
Hi. I'm excited to see a major open source player trying to take on
'open mobile' where Google and others have failed.

However, please do not attempt to craft a grand 'needed capabilities'
definition by commision! This seems to be what all other frameworks of
this type has done wrong. One will never be able to settle on a set of
eternal and sufficient set of capabilities - the field is simply
changing too fast. One day our ringtones are monophonic beeps, the
next they are full-blown multimedia experiences. One day we use
premium SMS to pay for things, the next we use NFC. One day we use our
mobile phones for calling other people, the next we use it for
navigation and photography. (The point here is not to list needed
capabilities, but to point out that the list is ever-changing!)

Instead of falling into the trap of thinking that we can define "one
API to rule them all", why not define a platform-neutral API for
managing native extensions/drivers via web apps? So, for instance, if
I wanted to install a new audio codec, there would be an API for a web
app to determine my platform, push the right binary to my device, and
have the OS install it.

Or do you have better plans for coping with the fast pace of
progress?

Anders Feder

On Jul 25, 11:49 am, 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

Re: Booting to the Web adicahya 9/20/11 10:27 PM
Hi

My name Adicahya, i'm a product designer from Jakarta, Indonesia.
Guys, if can,  i would like to contribute in UI design (and maybe
hardware design too)..i don't where to join.so, i just post one in
this list.
I hope you don't mind..

I've been supplying some idea to the webian project recently and post
some of my UI concept in their getsatifaction.com page.
I have post both desktop and mobile UI for them. If you like, you can
see them..

mobile UI concept
http://getsatisfaction.com/webian/topics/webian_mobile_ui
and for desktop/tablet UI concept
http://getsatisfaction.com/webian/topics/webian_activity_cluster_concept_ui

Anyway, i'm building a new UI which is an evolution from what i post
on webian. I would look similar but quite different in the logic
behind it. I'm thingkin about consistence UI for desktop, tablet and
smartphone UI based on a "browser" design.
I'll post them here once it finish.

And..nice to met you all, hope i don't drop it in the wrong place :)

Adicahya


Re: Booting to the Web Chris Jones 9/21/11 1:30 AM
Hello Adicahya,

The concepts look very pretty :).

The best place to get started with B2G is https://wiki.mozilla.org/B2G, which links to both higher-level and lower-level projects.  We have a dedicated mailing list now, mozilla-dev-b2g, so please follow up there.

Cheers,
Chris
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Re: Booting to the Web tim luigjes 11/2/11 1:44 PM
Is this project still alive?
Re: Booting to the Web David Rajchenbach-Teller 11/3/11 12:20 AM
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/2/11 9:44 PM, tim luigjes wrote:
> Is this project still alive?
> _______________________________________________ dev-platform
> mailing list dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Indeed, it is very much alive. You can drop by #b2g on irc to chat
with some of the people involved, or take a look at
https://wiki.mozilla.org/B2G#Contributing for other manners of seeing
the progress.

Cheers,
 David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOskDbAAoJED+FkPgNe9W+BIEH/2LMgtPRa3wM0PLaq1W+gQOU
thZohcGl+IiOb7+se2ilMl3C+OIwm9e2I1yku0KiMYOwEKlQiIpn3BlxXq45KXgd
+ZWZWDZHPKnWUykWPNgk+aQL3nZGrhATv8+wkCnuxbzJV2uIOT/5qJ6gSczNBTti
ghM6zktTlOkiC+0Ye8FogUiboo6sFRmm4cTa6v7eSEsdUBxTQSxDFA016SV2ftkg
Is/sRkUHCFPYnlQtY0kt+FED3rYPqjATsOf9Gc39KaZDu3/fzIgYrpO+8feuQ7VL
tM8gxGGtA3I0SN2of4T/sJXxOrvvCcBdV5zfP8XS1hD5ZtbkKKHVWixnB1Kc4Ag=
=C72W
-----END PGP SIGNATURE-----
Re: Booting to the Web alsaf 11/12/11 1:29 AM
I had previously commented on this topic from a perspective of
somebody who would love to get this working on my phone and in general
who would like to use a HTML GUI for desktop applications.

Since then I have become interested in lower level stuff like
electronics and embedded programming. From my understanding of the
project, B2G is going to use a stripped down Android to communicate
with the hardware. Also, from my understanding, B2G will be using HTML
apps rather than native apps so in effect, it will be handling all the
resource management, I/O and other functions associated with a kernel
that native apps would use. While it make sense and is quicker to use
an existing kernel for the low-level stuff, if the device drivers
could be written, would it take a lot of work for B2G to act as a
kernel and directly use the hardware?
Re: Booting to the Web Chris Jones 11/14/11 11:26 AM
----- Original Message -----
> From: "alsaf" <alfra...@gmail.com>
> To: dev-pl...@lists.mozilla.org
> Sent: Saturday, November 12, 2011 1:29:44 AM
> Subject: Re: Booting to the Web
> Since then I have become interested in lower level stuff like
> electronics and embedded programming. From my understanding of the
> project, B2G is going to use a stripped down Android to communicate
> with the hardware. Also, from my understanding, B2G will be using HTML
> apps rather than native apps so in effect, it will be handling all the
> resource management, I/O and other functions associated with a kernel
> that native apps would use. While it make sense and is quicker to use
> an existing kernel for the low-level stuff, if the device drivers
> could be written, would it take a lot of work for B2G to act as a
> kernel and directly use the hardware?

That would be a tremendous amount of work.  No one at Mozilla is going to write an OS kernel in the context of the b2g project.

That said, since in b2g Gecko will own all of userspace in essence, there may be opportunities to experiment with new kernel interfaces to e.g. improve resource management, particularly when memory is critically low.  But that's *much* different than writing a new kernel.

Cheers,
Chris
Re: Booting to the Web alsaf 11/14/11 12:03 PM
Thanks for reply Chris.

I was thinking that as quite a few functions, like you mentioned with
resource management, where in essence being duplicated, that a minimal
kernel could be written which b2g sitting upon it. As it would take a
lot of work to implement that, it doesn't sound feasible unless an
outside project would take it on.
Re: Booting to the Web alsaf 11/14/11 12:06 PM
Thanks to replying Chris.

I thought as functions were being duplicated, like what you mentioned
with resource management, a minimal kernel could be written with b2g
sitting on top of it. As you mentioned, it would take a lot of work to
do, it is not feasible unless an outside team was to take it forward.
Re: Booting to the Web saurab...@gmail.com 11/11/13 9:14 PM
Hi..
I am presenting on the topic Firefox OS. I need your help to develope some slides for "Thread Scheduling"in firefox OS. I am not able to find out any data regrading thread scheduling. Kindly help.
Re: Booting to the Web David Rajchenbach-Teller 11/12/13 2:55 AM
  Hi,

 As far as I remember, thread scheduling in Firefox OS is handled by the
Linux kernel, so if you are looking for documentation, you should
probably look in that direction.

Cheers,
 David

On 11/12/13 6:14 AM, saurab...@gmail.com wrote:
> Hi..
> I am presenting on the topic Firefox OS. I need your help to develope some slides for "Thread Scheduling"in firefox OS. I am not able to find out any data regrading thread scheduling. Kindly help.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
Re: Booting to the Web Thomas Zimmermann 11/12/13 3:54 AM
Hi,

There is nothing special about FFOS thread scheduling that I'm aware of.
Threads are implemented by the underlying Linux kernel and are scheduled
by the kernel itself.

We use an Android kernel, so thread scheduling on FFOS is affected by
wake locks. I don't know if we use cgroups* or nice levels for
fine-tuning scheduling behavior. We don't have RT scheduling, etc.

The b2g process, which is our main executable, contains a main thread
that is always ready for running (i.e., it's guaranteed to make forward
progress). And b2g uses a number of threads for off-loading long-running
tasks. These threads are scheduled when there is work for them to do,
but might also sleep; it depends on the thread's purpose.

Best regards
Thomas

* /sys/fs/cgroup is empty, so probably not

On 12.11.2013 06:14, saurab...@gmail.com wrote:
> Hi..
> I am presenting on the topic Firefox OS. I need your help to develope some slides for "Thread Scheduling"in firefox OS. I am not able to find out any data regrading thread scheduling. Kindly help.
Re: Booting to the Web Gabriele Svelto 11/12/13 7:27 AM
 Hi John,

> I am presenting on the topic Firefox OS. I need your help to develope some slides for "Thread Scheduling"in firefox OS. I am not able to find out any data regrading thread scheduling. Kindly help.

as Thomas already mentioned FxOS uses the regular Linux scheduler for
handling threads; this includes the main thread of each application as
well as DOM workers and other helper threads.

Currently we adjust nice values to prioritize process and thread
execution. Depending on the status of a process we assign it a different
nice level. We've currently got 7 levels:

MASTER - nice 0, used for the main b2g process
FOREGROUND_HIGH - nice 0, used for processes holding a CPU wakelock
FOREGROUND - nice 1, used for foreground processes
FOREGROUND_KEYBOARD - nice 1, used for the keyboard app
BACKGROUND_PERCEIVABLE - nice 7, used for background processes playing audio
BACKGROUND_HOMESCREEN - nice 18, used for the homescreen app
BACKGROUND - nice 18, used for all other background apps

As you can see some levels share the same nice values, that's because
those levels currently differ in the way they're treated by the
out-of-memory killer. All those values can be adjusted at build time via
preferences, you can find those here:

http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/b2g/app/b2g.js#l610

Within a process the main thread receives the nice value of the process
whilst DOM worker threads receive a nice value that is one point higher
than the main thread (thus they run at a lower priority than the main
thread).

If you're interested how process priorities are handled you can find the
relevant code here:

http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/hal/HalTypes.h#l79
http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/dom/ipc/ProcessPriorityManager.h
http://hg.mozilla.org/mozilla-central/file/54e8c6492dc4/dom/ipc/ProcessPriorityManager.cpp

We don't use cgroups as Thomas mentioned because we found them to be
hopelessly broken on certain kernels and we couldn't rely on them for a
solid implementation.

Being one of the persons who wrote this code I should really be doing a
write-up of this in our Firefox OS architecture page but I didn't have
enough time for it yet :-|

  Gabriele
Re: Booting to the Web Ben Kelly 11/12/13 7:42 AM
On 11/12/2013 10:27 AM, Gabriele Svelto wrote:
> Being one of the persons who wrote this code I should really be doing a
> write-up of this in our Firefox OS architecture page but I didn't have
> enough time for it yet :-|

I was actually thinking while reading your mail that it was a great
write up and should be on the page.  :-)

I took the liberty of adding it here:

   https://wiki.mozilla.org/B2G/Architecture#Threading

Hope you don't mind.

Thanks!

Ben
More topics »