907068 - Expose Inter-App Communication API to Non-Certified Apps

Status: RESOLVED WONTFIX

(Core :: DOM: Device Interfaces, defect)

Description

[Gene Lian (I already quit Mozilla)]

In the initiative step, we only expose inter-app communication API to certified apps only to meet the time line. Eventually, we need to make it available for the non-certified apps as well.

Comment 1

[:Harald Kirschner :digitarald]

This is blocking partner apps and only allows the music app so to give a great playback experience.

Can we revisit this and make sure we don't block this from other apps without good reason.

Comment 2

[Gene Lian (I already quit Mozilla)]

I only received the message from PMs that we only need to expose it for the certified apps for now. To enable it on the third-party apps, we still need lots of work on that, including introducing a prompt to allow permissions. I hope we can target it on the V1.4 at least, where we're having more important features under way on V1.3... We need to contact PMs to manage the timeline first.

Comment 3

[Fernando Jiménez Moreno [:ferjm]]

(In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #2)
> I only received the message from PMs that we only need to expose it for the
> certified apps for now. To enable it on the third-party apps, we still need
> lots of work on that, including introducing a prompt to allow permissions. I
> hope we can target it on the V1.4 at least, where we're having more
> important features under way on V1.3... We need to contact PMs to manage the
> timeline first.

There were also other alternative approaches for IAC that we should probably explore before exposing this API to the web. The WebAPI team wasn't happy with this solution and I know that Ehsan was looking for alternative approaches (i.e. XHR or SystemWorkers).

Comment 4

[(no longer active)]

(In reply to comment #3)
> (In reply to Gene Lian [:gene] (needinfo? encouraged) from comment #2)
> > I only received the message from PMs that we only need to expose it for the
> > certified apps for now. To enable it on the third-party apps, we still need
> > lots of work on that, including introducing a prompt to allow permissions. I
> > hope we can target it on the V1.4 at least, where we're having more
> > important features under way on V1.3... We need to contact PMs to manage the
> > timeline first.
> 
> There were also other alternative approaches for IAC that we should probably
> explore before exposing this API to the web. The WebAPI team wasn't happy with
> this solution and I know that Ehsan was looking for alternative approaches
> (i.e. XHR or SystemWorkers).

Yes, that's correct.  I don't have any concrete proposals yet though, but I will focus on that hopefully soon.

Comment 5

[Greg Weng [:snowmantw][:gweng][:λ]]

If we allow inter-app XHR, would some apps using tricks on the current front-end applications to simulate socket, like long-polling? I think in such case, inter-app WebSocket may be more closed to IAC, and it's a W3C standard, too.

(Or it would be even better if we allow both of them for apps).

Comment 6

[Greg Weng [:snowmantw][:gweng][:λ]]

Sorry, typo:

closed -> close.

Comment 7

[(no longer active)]

(In reply to comment #5)
> If we allow inter-app XHR, would some apps using tricks on the current
> front-end applications to simulate socket, like long-polling? I think in such
> case, inter-app WebSocket may be more closed to IAC, and it's a W3C standard,
> too.

I'm not sure what you mean... Can you please clarify?

Comment 8

[Greg Weng [:snowmantw][:gweng][:λ]]

As far as I know (heard from others), we want to allow apps fire and handle XHR to communicate with each others. So if the inter-app XHR is like what we used in the classical browser/server model, and for example we have two apps, like appFoo and appBar, the sequence would become:

1. appFoo want to send something to appBar
2. appFoo request to connect a socket on appBar (would be the 'server')
3. appBar response the request of appFoo (the 'client')
4. appFoo know the connection is ready, start to send the data
5. the connection would be closed after this session is done

Here, if appFoo need to send lots of data in different time, it needs to repeat the step 2 many times because XHR in its nature is not a persistent connection, but a mechanism that client must fire new requests and establish new connections every time it want to communicate with the server. So for front-end engineers, we would prevent to use the normal XHR model to prevent open too many connections and therefore we would face too many latency due to those handshakes. This is also lethal for those websites need to provide realtime service, like web-im or gaming, because the client must polling server frequently to keep the states get updated, and the connection effort may cause poor performance on both client and server. 

To solve this, we would use some tricks like long-polling or comet to keep the XHR connection even it normally should be closed after the request has been responded. This requirement had been fully satisfied after the WebSocket has been implemented in major browsers. WebSocket can provide:

1. Better performance because of its duplex and bidirection nature
2. No need to simulate socket by handling packets and states manually like what would happen in long-polling and comet
3. A standardized way to establish a connection between the client and the server and both parties can start sending data at any time

So if we or 3rd-party developers use IAC in apps to send realtime data between apps, Websocket is more proper, and cause less problems (compare to simulate it with the traditional XHR). If we only provide XHR, we may need to face the problems and requirements from front-end developers that already happened in the browser-server model.

Comment 9

[(no longer active)]

Replied to the dev-webapi thread.  Sorry for the delay!

Comment 10

[Krzysztof Mioduszewski[:tauzen]]

Hi Ehsan, what is the status of this bug? Are there any plans to finish this or introduce a different API which would allow inter-app communication? Is there some other bug which I can follow?

Comment 11

[(no longer active)]

We currently don't have any plans to expose the IAC API to non-certified apps.  I'm marking this bug as WONTFIX because there has been a lot of confusion about this, and it's better to adjust the status of this bug to reality.

If you have use cases for which there is currently no API that allows you to do what you want, please start a thread on dev-webapi and let's discuss better solutions to them.  Thanks!