I have seen this discussion on https://groups.google.com/forum/#!msg/mozilla.dev.platform/0t29OSSudOk/ePa44tM4AwAJ related to removing B2G code from gecko.
is it a blocker for the B2G OS project ? 
1 Like
From what I can see on the mailing list, the support B2G OS requires from Gecko is not such a big deal as it was with Firefox OS. Moreover people at Mozilla knows about the issue and are aware of the various implications. Iām quite positive theyāll decide to keep supporting the project by not forcing us to fork Gecko.
2 Likes
To be totally honest, this is a contentious topic inside MoCo. But I think we have good arguments to keep the gonk layer supported.
4 Likes
@benfrancis you already discussed about moving device specific apiās to a node server. Is there a possibility to do that (quickly) ? So that we donāt interfere with gecko.
There are a list of 30 APIs weād like to remove from Gecko or migrate into local web services, 10 have been removed so far and at least one other is in progress.
We have a proof of concept WiFi daemon which could replace the WiFi API and serve as a blueprint for other system services, but as far as I know nobody is actively working on this (contributions welcome!).
However, it is basically impossible to build Boot to Gecko without āinterferingā with Gecko as you put it. It may be possible to move some Gonk back ends for standard web APIs like the W3C Vibration API, W3C Battery API and W3C Wake Lock API out of the mozilla-central repository in some way, but as a minimum we need the Gonk widget layer and A/V back end, the Browser API, Input Method API and probably the Camera Control API. Out of those only the Browser API is used by Firefox.
Due to the monolithic nature of Geckoās architecture and lack of embedding APIs itās currently impossible to build B2G without having at least some code in mozilla-central. The B2G community could fork Gecko and create the āBoot to [fork of Gecko]ā project, but maintaining a fork of an entire web rendering engine is a huge task and it would no longer really be āBoot to Geckoā.
So yes, we should be worried about it.
2 Likes
While we should be worried, we should also start the work of implementing those APIs outside of Gecko: that will prove that we are committed and serious, and at the same time lower the maintainance burden for everyone. Anyone disagrees ?
2 Likes
It would be like a big add-on or plugin ?
IMHO more like something completely separate handled at build time. The WiFi example linked by Ben earlier is what we should work on: node.js (or anything else) living next to Gecko.
I know some people would prefer we make use of Rust :). Iād be happy with any.
But we will have to send and receive data between gecko and this other server.js ? :-/
( ok, with a little script to split the system and front-end part, it could be automatic and I wonāt have to take care about this communication to develop an app, but itās a little bit ugly :-/ ā¦ and to debug ā¦ )
please explain the possibilities of adding nodejs & npm to b2g os ? We have many npm modules 
phone becomes a full fledged server
The big picture as Ben and Alex said is that we need a system daemon that gaia talks to. Itās not very different from what we do already for eg. bluetooth and even with the RIL daemon, except that these talk to gecko through some IPC.
Since gaia is web based and canāt use things like unix domain sockets for IPC, we will have to go with http and/or websocket (I think websocket is enough) to communicate with the daemon. Iām not worried about the performance here, this is not gonna be a high traffic service. What we need to figure out though is how to get that secure to prevent a random webpage to connect to the system websocket.
From an implementation point of view, Iām the Rust fan This is the perfect choice for such a system daemon. We should start with a simple case like wifi (rewriting the node.js one in Rust) to test the waters. Some features will be very hard to move out of gecko, like the telephony stack (look at http://searchfox.org/mozilla-central/source/dom/system/gonk/ril_worker.js for a taste of the complexity) but we can still start with all the easier ones.
Iām a Rust fan too, thatās the one language I almost understand a bit. I see the benefits in being independent from gecko code. Do you think we have the man-power and know-how to do something like that? How long may it take? And will Mozilla tolerate b2g code in gecko for so long?
almost fainted 
The only way to really know is to try. That wonāt be easy but itās not impossible to achieve.
And coming from someone who was part of the early B2G kick starter, it means something
I have to admit I took part into that
Is a single system daemon that does all system-related tasks in one envisaged, or could it be a loosely coupled collection of system āmicro-servicesā that each perform a separate job? e.g. network manager, RIL manager, etc etc.
I was thinking some more about having a system daemon that gaia talks to, and I was wondering if perhaps we could look into websockifying D-Bus.
The benefits of using D-Bus would be:
- Already builds on Android (see here); only dependency is glib, I think
- A large number of system services already talk to D-Bus, including:
- Flexible authentication
- Can handle starting and stopping services on-demand
- Rust support exists, so d-bus services that we lack could be written in Rust
- Any D-bus services written for B2G OS might get use/support from other projects as well.
- Can talk over TCP already.
Websockify allows us to wrap any TCP socket server and turn it into a websocket server, ideally talking the binary ws protocol. The benefits to using websockify would be:
- AS I understand it, emscripten has limited support for compiling BSD socket code from C into websockify code (see here). That may make it easier to get a dbus client on the web up and running.
- There are several implementations, including an nginx module ā something will hopefully work on android, or we could write a rust version of websockify perhaps.
- Potentially zero coding necessary to get something basic going
It might be that this setup is far too heavy or dangerous to be used in production. However, we might still benefit from adopting the d-bus protocol even if we didnāt end up using d-bus itself. In that case, using d-bus itself to begin with would be a fast way to get going, and we could change it out for something leaner that quacks the same at a later stage. The same would go for using d-bus with any of the above services.
There are Iām sure lots of alternatives to websockify. We could for instance look into serializing the dbus protocol into JSON. Iāve had a quick look online and found the following existing efforts:
- The cockpit project has something called dbus-json3
- ā¦ err, thatās all.
4 Likes
Why not use D-Bus directly in an Add-on/pluggin instead of communicate by wraping all with websocket ?
This could be an option too. The reason not to go this way at the moment would be that we donāt have an addon/plugin system available in b2g (as far as I know).
However, if we are using dbus anyway then switching from a websocket to a native connection would presumably be easier than if we used some custom protocol
1 Like
Traditionnal add-ons are not an option, since that would mean using chrome JS in gaia which is a no-go. So websockets are really the only option from a protocol point of view. I donāt expect performance issues, itās not like we have that much data to transfer around.
About using d-bus, why not if that gives easier access to some features. Actually the first one to prototype would be mozAlarams since the old backend was removed from Gecko.