How does this differ from window.postMessage? I thought postMessage was going to be the main way that we did cross-origin communication between apps and service workers?
The fxos security team has been discussing ideas for how crypto-hardware (e.g. secure elements, TPM, etc) vendors could expose their hardware to web apps in a somewhat generic way. One idea was to have vendor-supplied SW that presented an API via cross-origin message passing. The SW translates API call messages into APDU's that get sent to the hardware and returns the results. I think we were assuming that the main message passing mechanism would be postMessage. It sounds to me like fetch()/navigator.connect() is more network/offline resource oriented and would be a better fit for what we are thinking. --dave On Tue, Dec 16, 2014, at 11:33 AM, Jonas Sicking wrote: > On Tue, Dec 16, 2014 at 11:00 AM, Alex Russell <slightly...@google.com> > wrote: > > On Mon, Dec 15, 2014 at 6:25 PM, Jonas Sicking <jo...@sicking.cc> wrote: > >> > >> On Mon, Dec 15, 2014 at 2:50 PM, Alex Russell <slightly...@google.com> > >> wrote: > >> > On Thu, Dec 11, 2014 at 6:17 PM, Jonas Sicking <jo...@sicking.cc> wrote: > >> >> > >> >> On Thu, Dec 11, 2014 at 5:56 PM, Alex Russell <slightly...@google.com> > >> >> wrote: > >> >> >> One solution would be to at that point allow the SW from the other > >> >> >> origin to install itself, which means that you can then just talk to > >> >> >> it as a normal installed SW. However installing a SW could take > >> >> >> significant amount of time. On the order of tens of seconds if the > >> >> >> user is on a slow connection and the SW represent an app with heavy > >> >> >> resources. > >> >> > > >> >> > I'm OK with it taking time. The discovery phase of a n.c() setup is > >> >> > async. > >> >> > >> >> This is along time though. > >> > > >> > I don't imagine these are the same SW's as the main app in the common > >> > case. > >> > As a result, these can (should?) be custom built, be lighter, and > >> > perhaps > >> > can communicate with the main app SW (if it's installed). Manually > >> > visiting > >> > these URLs seems, to me, to be about viewing an admin page for a service > >> > endpoint. So yes, install is at least one network RTT (probably > >> > several), > >> > but I'm not sure that's fatal. At least you can communicate what's going > >> > on > >> > (to the extent that you have UI up and running). > >> > >> This certainly sounds interesting, but I'm not sure how it fits with > >> the current registration API. Presumably the SW which handles these > >> requests (whether they come from a fetch() call or a .connect() call) > >> would need to be atomically updated with the SW which handles the > >> website itself. So the SW which handles facebook service calls would > >> need to be atomically updated with the SW which handles facebook app > >> UI. > >> > >> Additionally, SW is currently all about the scope argument. But it's > >> not clear what scope you would use for a service SW. > > > > > > I think you'd want to have a scope like: > > > > https://example.com/services/name/v1/ > > > > As the scope for a SW hosted at: > > > > https://example.com/services/name/v1/service.js > > I'm not sure I understand. This seems like a new way to interpret SW > scopes? How do these URLs relate to .connect()? Are these real URLs > that actually are fetched over the network apart from the SW script > itself? > > FWIW, I think this shows that basing SW registration entirely on > scopes for pages that it serves is causing problems for other uses of > SW. > > >> I'd definitely be interested to see a proposal which addresses these > >> issues. > > > > > > We've been chatting about this and it feels like there's a pretty big design > > space that includes permutations of: > > > > postMessage/ports to/from a local SW > > a look-aside fetch() that is "local only", e.g. doesn't go to the network if > > there isn't an existing SW to handle it > > a look-aside fetch() that could fault to the network if it isn't locally > > handled > > > > They don't seem exclusive, either. We could imagine making more than one of > > them available. > > Agreed. > > > There's also an independent choice about the question of installation via > > headers. > > > > We're gonna write these up because it feels like it'd be useful to have some > > common understanding of the design alternatives. > > Looking forward to that. > > > It ALSO seems like we should get together and talk with higher bandwidth. > > Perhaps some F2F time in January would be useful? Is that possible? > > I can't speak for others, but I'll be in SF in January. > > / Jonas > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
