Hi all,
A lot of the debate thus far about how to recover from Mozilla’s decision to remove all B2G code from Gecko has rightly focussed on how to get Gecko to run on phone hardware as the root UI once again. The main two possibilities suggested thus far are:
- Use Android and Fennec; and
- Retain the Gonk/B2G code in Gecko by forking. This latter option is being pursued by the Astian OS group and maybe some others besides.
In addition to these two options, there have been many other suggestions about trying to base something on one of the many alternative projects out there (Mer, Sailfish, Ubuntu Touch, NodeOS, Chromium OS, etc. etc.). Beyond phones, there are potentially opportunities to be had in other embedded environments too.
As an aside, I have become interested in the idea of getting a desktop environment available using electron (or positron).
In short, there is no shortage of environments where a browser environment could potentially be booted into, especially if one looks beyond phones to other form factors, and beyond gecko to other browser engines (I know, sacrilege). In fact, this should be one of the major strengths of a project that focusses on the web – web browsers are everywhere!
There are some promising signs from the effort to run Gecko/Fennec as the root window on Android, and as such some people have started questioning how this browser window is going to be able to do all of the other things that we expect from a phone / tablet / whatever (e.g. answer phone calls, send SMSes, etc.). This question was in fact already an open one after the death of the mozapps API, before Mozilla started removing B2G code from Gecko.
My understanding from all the various conversations I’ve seen is that we are looking at something like the following:
-
A minimal “shell” process that is able to do window management and other tricky things that ordinary browsers can’t. In B2G/Gaia, this is the part of the system app that absolutely has to run as chrome at present. Although the shell can use HTML5 (as in B2G), it isn’t really a webapp because it needs capabilities that are not available in the web (e.g. the mozbrowser API).
-
One or more web services that can be run on the device to allow access to all the things that we can’t get using standard web APIs (e.g. SMS messaging, telephony, filesystem, and many more). This will need to include a permission/security system controlling which webapps are allowed access to what which services.
-
Web apps that know how to use the above permission system and web services (probably via a set of Javascript libraries) to perform tasks and respond to events. In theory it should be possible to implement every window that itself isn’t a window manager (i.e. doesn’t contain other windows) as a web app. That includes even things like the tray thingy at the top of the screen, and the settings app.
Parts 1-2 of the above will have implementation specifics. For instance:
-
As has been much discussed, the shell depends a lot on whether the underlying system is using Android, or whatever. We may however be lucky enough that all gecko-based shells can at least use the same HTML5 code for window layout. Still, compiling gecko in each environment will be a lot of work.
-
Web services will probably depend a lot on what sort of system the shell is running in. In Androidland, it might make more sense to use the Java APIs already available. In other smartphone environments (if that ever becomes viable), something like Sailfish’s ofono/connman/bluez/pulseaudio stack might be preferable, or it might actually be preferable to write services from scratch, or based on the old gonk code. On desktop, some dummy hardware services would be handy for being able to make fake SMSes, etc.
It occurs to me that although these two components may need to be implemented quite differently in different environments, it should be possible to agree on a standard “Boot2Web” architecture such that a webapp that is working with such an architecture can function regardless of the underlying browser, etc. This architecture might cover:
- Explaining how web apps and web services would coordinate with the shell to achieve things like opening new windows, displaying alerts, etc.
- Determining the web APIs for the web services, including how to request permissions for APIs
- Potentially creating JS libraries that projects can use to talk to the web services without worrying about how they are implemented
- Working through how complicated use cases like receiving a phone call will work.
I know it’s very early to be talking about standards when there’s not even a working android port yet. However, I think it might be helpful nonetheless for the following reasons:
- A lot of people who were following B2G have gotten cold feet about supporting a project that is making heavier use of Android than B2G did. If it can be made clear exactly where the android port fits in to the overall scheme of things, and what someone needs to do to port to another environment, I think this will probably reassure a lot of people.
- This would give people who are good at thinking about high-level stuff, but not coding a place to
- As I mentioned there is already a new project that proposes to fork gecko. If standard APIs can be agreed on, then hopefully it will be possible to make webapps that work on both projects.
- There are a lot of unknowns around how complex use cases will be handled. Talking the use cases through could be very useful.
- Standardisation would ideally lead to new implementations, making the project less at risk of another disaster like the one in September. e.g. if Mozilla decides to discontinue Firefox for Android one day.
I’ve been very impressed with the way WebAssembly standardisation has proceeded using a github repo, issues, milestones and pull requests to manage the process. If others think that my proposal has merit, perhaps we could create a similar repo for this work?
