Expose Inter-App Communication API to Non-Certified Apps

RESOLVED WONTFIX

Status

()

Core
DOM: Device Interfaces
RESOLVED WONTFIX
4 years ago
3 years ago

People

(Reporter: Gene Lian (I already quit Mozilla), Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

4 years ago
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.
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.
Severity: normal → critical
Flags: needinfo?(gene.lian)
(Reporter)

Comment 2

4 years ago
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.
Depends on: 897169
No longer depends on: 876397
Flags: needinfo?(gene.lian)
(Reporter)

Updated

4 years ago
Depends on: 876397
(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).
(Reporter)

Updated

4 years ago
Severity: critical → normal

Comment 4

4 years ago
(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.
(Reporter)

Updated

4 years ago
Blocks: 983002, 984717
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).
Sorry, typo:

closed -> close.

Comment 7

4 years ago
(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?
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.

Updated

4 years ago
Flags: needinfo?(ehsan)
(Reporter)

Updated

4 years ago
Blocks: 876397
No longer depends on: 876397

Comment 9

4 years ago
Replied to the dev-webapi thread.  Sorry for the delay!
Flags: needinfo?(ehsan)
(Reporter)

Updated

3 years ago
Assignee: gene.lian → nobody
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?
Flags: needinfo?(ehsan.akhgari)

Comment 11

3 years ago
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!
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(ehsan.akhgari)
Keywords: dev-doc-needed
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.