On Wednesday, December 10, 2014 9:46:58 AM UTC-8, Ehsan Akhgari wrote: > 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?
"Work with" is a bit too vague here. I think you're suggesting to change which SW cross-origin fetch() calls are routed to. Right now, https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#on-fetch-request-algorithm (called from https://fetch.spec.whatwg.org/#http-fetch) specifies in step 13 that 'fetch' contexts go to the client's SW, not the target URL's SW. So, what are the implications of changing that? We'd have to ask Anne and Alex, at least, to be sure, but I can think of a couple problems: 1) Sites wouldn't be able to cache cross-origin resources until the other origin installed a SW. 2) Users could more easily write infinite loops between SWs, since at no point would they be guaranteed to bottom out at the network. We could solve the first with an extra flag to fetch(), letting users explicitly control which origin's SW gets the request, but we can think of navigator.connect() as exactly that flag, followed by some streamlining because of the expected target. Jeffrey _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
