On 2014-12-10 12:21 AM, Nikhil Marathe wrote:
(cross posted dev.b2g since this seems very relevant to it, but please keep
the discussion on dev.platform)
Hi All,
As part of the ServiceWorker initiative [1], Google is proposing a
`navigator.connect` API [2] to allow cross-origin ServiceWorker
communication. This post is mostly a notice to inform everyone of this
unofficial draft API.
This seems similar to our Inter-App communication API [3] and I'm sure the
authors and users of that API have feedback that should be incorporated in
a cross-web (non-b2g-specific) API. There also seems to be overlap with
some use-cases for Web Activities [4].
This is a good opportunity for us to influence how cross-origin messaging
is implemented at an early stage. If someone wants to drive this from
Mozilla's side, please "raise your hand".
I am very interested in this problem, and in fact I've been thinking
about what we should do for cross origin SW communications for a while.
:-) I do support the idea but I'm not convinced that we need a
specific API to talk to the SW (such as navigator.connect.)
What I have been envisioning is allowing SWs that are registered with
the UA to respond to cross origin fetch requests made through XHR/fetch
even from documents that are themselves not controlled by a SW. The
reasoning I have for this is as follows:
Currently on the Web, the defacto way that applications talk to each
other cross origin is through XHR using CORS. See the numerous HTTP
based APIs that are developed by various organizations that are used by
Web applications right now. With service workers, we are going to have
a Web that is usable off-line, and we can also use SWs to do things such
as smarter caching on the client side. The next interesting use case
would be to enable the usage of these HTTP based APIs offline (or doing
smart caching on the client side, etc.)
I see no great reason to require Web applications to write specific code
for this, though. Let's say that my application XHRs into
<https://socialnetwork.com/get/friends> in order to get the user's list
of friends. It would be nice to allow that request to be handled by the
service worker registered for socialnetwork.com and give that SW control
over whether it wants to respond to the request without going to the
network. This has the additional advantage that people's code and all
of the ecosystem that they have built on top of XHR based APIs over the
years will just work offline once the service providers get their SWs
registered.
The downside of this approach is of course relying on the service
providers to get their SWs registered, which may require the user to
navigate to the service provider's origin, but I suppose that matches
the security model of the UA prompting for the installation of the
service worker, etc.
So I guess my biggest question so far is: what will we gain by adding
another API specifically for connecting to the service worker? Do you
think we can avoid doing that and focus on making XHR/fetch work with
cross origin SWs?
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
