Community maintained API's?

bluettooth, wifi, NFC these will be maintained by mozilla because these are important for connected devices too. And everything moved to web standards. So, Regarding the community API’s my guess is:

  • Call, SMS
  • Contacts
  • Gallery (SD Card ?)
  • LED
  • Camera
  • Any more guesses ?

I’m no expert here, but I guess any API supported as a web standard would be a great benefit. Is there no web standard for camera/microphone?

getUserMedia() probably does not cover all the usecases that the mozCamera API provides, such as controlling flash, etc.

1 Like

there is a web API for camera and microphone but i don’t know how good these can be used on mobiles… As said by @lissyx flash doesn’t come under it.

Another good place to look is the Firefox OS Module Owners list.

The area which is definitely smartphone-specific is the Radio Interface Layer. I would suggest the Contacts API is possibly smartphone specific too (can we do without it and just have the contacts app use IndexedDB?).

  • Radio Interface Layer
  • Telephony - dom/telephony
  • Mobile Message - dom/mobilemessage
  • Mobile Connection - dom/mobileconnection
  • ICC - dom/icc
  • Voicemail - dom/voicemail
  • Cell Broadcast - dom/cellbroadcast
  • dom/system/gonk
  • ipc/ril
  • Contacts
  • dom/contacts

There are many APIs being removed as part of the transition project which will therefore not need owners including:

  • Apps
  • Web Activities
  • System Messages
  • Inter-app Communication
  • Data Store
  • Engineering Mode
  • Mobile ID

There are other APIs which are used by smartphones but may still be needed for other Mozilla products like Smart TVs and other connected devices:

  • Bluetooth
  • dom/bluetooth
  • ipc/dbus
  • ipc/unixsocket
  • NFC
  • dom/nfc
  • system/nfcd
  • ipc/nfc
  • dom/system/gonk/nfc
  • WiFi
  • dom/wifi
  • ipc/keystore
  • FM Radio
  • Camera
  • Device Storage
  • Alarms
  • Input
  • Web Speech
  • System XHR
  • TCP Socket

I would suggest that for each of these APIs we should consider whether they are still needed, whether new web standards can replace them or whether they could live outside of Gecko (e.g. as a local web service).

For example, could Device APIs like Bluetooth, WiFi, NFC, FM Radio, Camera, Device Storage and Telephony be replaced with local web services using HTTP or WebSockets and talking directly to the Android HAL underneath? Are networking APIs like SystemXHR and TCPSocket needed any more if the system UI is chrome and there are no privileged apps? Can we think of an alternative for the Alarm API based on Service Workers? Could we expose Bluetooth and Web Speech to the open web based on the emerging W3C specifications?

The Browser API is now used inside Firefox and is likely to continue to be maintained by Mozilla.

Also remember they are not APIs but there are many apps in Gaia which may require new owners.

So I’d say the most obvious pieces which may need new owners are the telephony APIs and the non-system Gaia apps. For other areas it is currently less clear.

2 Likes

thanks for explaining this :slight_smile:

@benfrancis I saw a guy named Joan Ciprià working on clock chrome app currently & he is almost done. He shared some screen shots in telegram group.

this seems like waste of time to me. He should rather try to fix the existing Clock app instead of creating a new one.

i asked him the same, but he said he is comfortable with building from scratch

Hi guys! Yes, Actually I’m working on a clock chrome app. Now I’m dealing with the alarms part.






What is a chrome app? How much of this could you build with the web? What is missing to allow you to build the whole thing as a web app?

What do you mean?

You said that you’re working on a “clock chrome app”. I assume that this means it is implemented as chrome (chrome://). I’m asking what would prevent you from implementing this as web content (http://)? For example http://www.clocktab.com/

Our goal is to build as much as possible with the web.

I suspect the main missing piece would be the Alarms API?

1 Like

Oh sorry, I was using the chrome term only as “web app without API’s”. I was confused. The clock app is purely a web app (http://).
Yes, indeed I have built all except the alarms. Next days I will work on it and I guess I will have problems without APIs.

That’s great! I was confused by your use of the term chrome :slight_smile:

It sounds like what you’ve built is a web app. Perhaps you could add a web app manifest and consider using Service Workers for offline functionality if you don’t do those things already.

I think we’re going to need an Alarm API of some kind to build any alarm features, but let us know how you get on. Perhaps you could host this web app somewhere (e.g. GitHub pages) so that people can start to try it out?

1 Like

@benfrancis does mozilla provide any security measures for apps on B2GOS, or the community should handle it ? I mean if a web app tries to gain access like the chrome apps.

Hi @kskarthik,

Firstly, there is no such thing as a chrome app (well, except for Chrome Apps!). In B2G’s new architecture there’s chrome and there are web apps.

A web app can access everything websites can access and can request permissions from the user as usual (e.g. geolocation).

The system chrome has all permissions granted by default and can access privileged APIs which aren’t accessible to web content. All chrome code is code reviewed before it can land in the B2G codebase to ensure it is safe. The security team is also looking at other ways we can isolate parts of the system chrome for added security.

I hope this answers your question.

2 Likes

Regarding the Alarm API, I’ve noticed that Web Extensions have the ability to create alarms. I wonder whether an alarm function could eventually be implemented as an add-on.

that sounds interesting. And we could pre-install that add-on I assume?

You mean as an add-on or as a classic web-app too ?
This would allow people to create new clock app, and that’s a really good point.
So we might keep the alarm app as a classic one, and not a part of chrome.