On Wednesday, December 10, 2014 12:11:39 PM UTC-8, jyas...@chromium.org wrote: > 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
Well, that's not entirely clear. Both sites could maintain caches. > 2) Users could more easily write infinite loops between SWs, since at no > point would they be guaranteed to bottom out at the network. I'm more worried about the memory implications for low-spec devices of the russian-doll design for SW fetches. We've avoided it thus far for these reasons. > 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. The goal of the navigator.connect() effort is a much more general messaging and services bus. I'm optimistic that we could do something with it that makes many of the nested-fetch use cases both easier for developers to comprehend and better for runtimes to manage. I'm not as optimistic about russian-doll fetch handling and, as we have thus far in SW's design, want to wait until we have a compelling need before going that route. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
