On Wed, Dec 10, 2014 at 9:46 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> 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. > I like this idea. It would even be possible to create some lib that used a bit of JS reflection to auto create fully RESTful APIs from the functions exposed to cross-origin in the SW script. But I'm getting ahead of myself :) The fetch() based API won't be as user friendly as postMessage() for gossiping (where the two SWs are having an entire conversation rather than just a couple of exchanges), but it should be easy to abstract that away into a library too so that: var ipc = new LibIPC('//foo.com') ipc.send("/addToCart", "itemid=4").send("/useCachedCredentialsToPay", "authToken=baz").then(function() {}, function() {}) and underneath the lib would chain calls to fetch() and deal with response Promises accordingly and resolve the then() appropriately. CORS can be used in lieu of event.acceptConnection(). I guess having some primitives for structured clone like behavior would be nice. That too can be handled by use of Response.blob() and FileReader[Sync]() on workers, but having primitives means that UAs could optimize the structured clone behind the scenes instead of actually creating Blobs. (Aside: Sometimes I wish we could create a smaller rendering engine that had no UI and ran exclusively workers and their DOM APIs and make that the Firefox OS system process) Nikhil _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
