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'd definitely be interested to see a proposal which addresses these issues. / Jonas _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
