A number of subdirectories of dom/ were added for b2g and are being built unconditionally on all platforms. Some of these should probably be ifdefed. The ones worth looking at, IMO: activities/ alarm/ apps/ bluetooth/ camera/ cellbroadcast/ contacts/ datastore/ devicestorage/ filesystem/ fmradio/ icc/ mobileconnection/ mobilemessage/ phonenumberutils/ telephony/ voicemail/ newapps/ Some of these should probably be if CONFIG['MOZ_B2G'].

Hi Gregor, Could you help to assess whether we still want these b2g APIs? Thanks!

Even the ones that are still being kept by b2g need to be #ifdefed out on b2g. The typelibs for some of these are quite large and we're also building IPDL code for them (we may need to add preprocessing to IPDL or something).

DataStore API is dead already on pine and m-c, Apps is going away soon as far as I remember.

newapps/ can die safely. And I guess everything else can be safely ifdef under B2G.

As I understand it the following APIs have been removed on the pine branch (soon to be merged back into mozilla-central): * Apps API (apps/) * Web Activities (activities/) * System Messages (messages/) * Data Store (datastore/) * Inter-app Communication * Engineering Mode * RequestSync The MobileID API is in the process of being removed and we still have some cleanup to do to fully remove the remnants of the Apps API. I hope we'll be removing more APIs as we find alternative solutions outside of Gecko, but for the time being as Alex said IFDEF B2G seems OK.

the apps API has not been removed yet. I have a wip, but it's very invasive so I'd rather land directly on m-c after we merge Pine to not bloat the merge itself.

(In reply to Ben Francis [:benfrancis] from comment #5) > As I understand it the following APIs have been removed on the pine branch > (soon to be merged back into mozilla-central): > * Apps API (apps/) > * Web Activities (activities/) > * System Messages (messages/) > * Data Store (datastore/) > * Inter-app Communication > * Engineering Mode > * RequestSync > > The MobileID API is in the process of being removed and we still have some > cleanup to do to fully remove the remnants of the Apps API. > > I hope we'll be removing more APIs as we find alternative solutions outside > of Gecko, but for the time being as Alex said IFDEF B2G seems OK. #Resetting owner before clearing out clear plan. Hi Ben, Do you also have a plan to remove other functional APIs (bluetooth, fmradio, voicemail...) than you mentioned or they are still needed as community might need them after pine is merge back to m-c?

Currently these other remaining APIs are still in use by the B2G project, but when pine merges into mozilla-central most if not all of them should only be exposed to chrome code as there will be no mozApps permissions any more. I'm proposing an alternative approach for the APIs which are not on a standards track to use a services based model using a local web server so that we can gradually move these APIs out of Gecko, but that's going to take some time. I hope to explore this further as part of Project Tablet [1], but for now the existing APIs will continue to be exposed only to chrome (e.g. to make the dialer work). These APIs can safely be built only for B2G and through the "Web or Dead" [2] initiative for Gaia we can gradually move more of them out of Gecko. Kyle, does this answer your question? One other question, are there plans to evolve the Bluetooth and/or Filesystem APIs towards the Web Bluetooth [3] and File API [4] draft specifications at the W3C? It looks like the File API has been discontinued but Web Bluetooth is active and implemented behind a flag in Chrome. I'm not sure the Filesystem API is even actually used by B2G, but it seems like Web Bluetooth could be useful for both B2G and Firefox? 1. https://wiki.mozilla.org/Connected_Devices/Projects/Project_Tablet 2. https://groups.google.com/d/msg/mozilla.dev.fxos/huMYIK3rymc/eFdrbBFMAQAJ 3. https://webbluetoothcg.github.io/web-bluetooth/ 4. https://www.w3.org/TR/file-system-api/

Some variant of the filesystem API is happening. I don't think Web Bluetooth is though.

Will FlyWeb need or want Web Bluetooth?

(In reply to Olli Pettay [:smaug] (on vacation for couple of days) from comment #10) > Will FlyWeb need or want Web Bluetooth? I don't want to speak for anyone, but I'm confident I remember Gregor said they needed it in FlyWeb

Just a quick note to say that on Project Tablet Thomas has now landed an early proof of concept of a WiFi configuration daemon running on Node on the device, as a replacement for the WiFi API in Gecko. You can test it out by building B2G with the "project-tablet" config on a Sony Z2 tablet and loading the WiFi configuration UI via http://localhost. The idea is to eventually create local system REST web services which are called from the system chrome (e.g. about:settings). This provides an encouraging proof of concept of how we can phase out many of these device APIs in Gecko. There are further discussions currently ongoing to come up with a detailed plan.

An unspecific bug like this isn't too useful.