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
