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'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. 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. 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? Regards _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
