Should we worry about this?


(Sai Karthik Karra) #1

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 ? :confused:


#2

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.


(Fabrice) #3

To be totally honest, this is a contentious topic inside MoCo. But I think we have good arguments to keep the gonk layer supported.


(Sai Karthik Karra) #4

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


(Ben Francis) #5

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.


(Lissyx) #6

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 ?


(simon g) #7

It would be like a big add-on or plugin ?


(Lissyx) #8

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.


(simon g) #9

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


(Sai Karthik Karra) #10

please explain the possibilities of adding nodejs & npm to b2g os ? We have many npm modules :slight_smile: phone becomes a full fledged server


(Fabrice) #11

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


#12

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


(Fabrice) #13

The only way to really know is to try. That won’t be easy but it’s not impossible to achieve.


(Lissyx) #14

And coming from someone who was part of the early B2G kick starter, it means something :slight_smile:


(Lissyx) #15

I have to admit I took part into that :slight_smile:


(Alastair Pharo) #16

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.


(Alastair Pharo) #17

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:
    • Bluez 5 (bluetooth)
    • ConnMan (network manager used by Sailfish)
    • ofono (modem manager that can talk to RILD; used by both sailfish and ubuntu)
  • 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.

(simon g) #18

Why not use D-Bus directly in an Add-on/pluggin instead of communicate by wraping all with websocket ?


(Alastair Pharo) #19

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


(Fabrice) #20

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.