974034 - Refresh the Inter-App Communications API

Status: RESOLVED WONTFIX

(Core :: DOM: Device Interfaces, defect)

Description

[Jim Porter (:squib)]

The Inter-App Communications API, while useful, isn't particularly useable, mainly due to how the API is designed. Almost immediately, we were forced to create a wrapper for it (IACHandler[1]) to make it more manageable. We should try to remove the need for this wrapper.

There are other issues I've encountered, like how the "listening" side of an IAC connection is automatically opened when the broadcasting side starts sending messages. This works for the use cases we have now, since the system app is the listening side, but it's inappropriate for other cases.

We may also want to figure out ways of how to prioritize multiple broadcasters, although this might be an app-specific issue. For instance, both the Music app and the FM Radio want to show "now playing" notifications in the system app, and we need to figure out how they should behave when they're both open.

Also, feel free to recategorize this into Gecko if need be.

[1] https://github.com/mozilla-b2g/gaia/blob/master/shared/js/iac_handler.js

Comment 1

[:Harald Kirschner :digitarald]

I hope part of this are steps to make the access privileged. If needed Partner Engineering can provide use cases from app developers that are blocked by IAC API only being available to certified apps.

Comment 2

[Jim Porter (:squib)]

IAC should already be available only to certified apps. However, I believe the plan is to ask for permission on a per-channel basis. This is good for, e.g. third-party music apps. We should be allowing them to hook into the "now playing" notifications.

Comment 3

[Jim Porter (:squib)]

To solve the first part of these issues (the one that IACHandler works around), we probably need to the IAC subscribers to be able to call a subscribe function on a per-keyword basis. The current strategy of having one place for *all* IAC keywords doesn't work when independent parts of the code need to set up IAC subscriptions for different keywords.

We could go a step farther and do like IACHandler, though. That is, we'd fire DOM events for each IAC message. The downside with this strategy is that we'd have to figure out how to *send* messages back to the publisher.

Comment 4

[(not reading bugmail) Nick Desaulniers [:\n]]

Please take into account how a developer would use feature detection to see if IAC was available (or changed), since they have to support multiple versions of Gaia, even though the Gaia apps themselves don't.

Comment 5

[Jim Porter (:squib)]

(In reply to Nick Desaulniers [:\n] from comment #4)
> Please take into account how a developer would use feature detection to see
> if IAC was available (or changed), since they have to support multiple
> versions of Gaia, even though the Gaia apps themselves don't.

I don't think we actually need to worry about this, since IAC is only available to certified apps, unless something changed since I last looked at this. I suppose a partner could have written something that uses IAC, but surely we can just tell them to use the new version?

Comment 6

[:Harald Kirschner :digitarald]

Part of the refresh should make the API privileged as said in comment 1.

Comment 7

[Jim Porter (:squib)]

(In reply to Harald Kirschner :digitarald from comment #6)
> Part of the refresh should make the API privileged as said in comment 1.

I imagine changing the permission model would be independent of any API changes, but we should definitely start thinking about opening this up beyond just certified apps.

I think the old design docs have some thoughts about how to do this, and they should probably work for us no matter what the API itself looks like. It's probably wise to do this *after* we've fixed up the API to our satisfaction though, so that the API is relatively stable for when third parties start playing with it.

I'll try to come up with some ideas of what *I'd* like the API to look like over the weekend. Then people can comment on it and incorporate any other use cases we might need.

Comment 8

[Jim Porter (:squib)]

I think it's safe to say we're not going to do this. If someone disagrees, feel free to reopen this.