Re: [w3c/ServiceWorker] Allowing multiple scopes (& should scopes be primary key?) (#566)

I feel that this issue and others like issue #1026 or issue #1272 and the [long-thought-after static routes](https://github.com/w3c/ServiceWorker/issues/920#issuecomment-229016073) are similar in that they are about refining if/how a Service Worker gets involved. 

I know that there is strong interest on those issues, including from Google and Facebook. I'm wondering if we can identify a path forward. So, here is my modest contribution to the discussion.

Currently, we can only define that a Service Worker gets involved for a navigation to anything below its scope (prefix match) on a given origin.

I've heard about the following use cases:
 1. A way to avoid one's SW oversteps on other products, in particular when the scope doesn't end with a slash, e.g. /foo matching against /football. This creates an on-going burden on other teams as they have to register a no-op SW on their more specific scope. This is issue #1272.
 2. A way to skip the SW for certain resources and/or paths. This is issue #1026.
 3. A way to get an existing SW also involved on navigation to related scopes, assuming no conflicts. For instance, get a SW registered to example.com with scope /productA to also control /settings. This particular issue.
 4. Future-looking: the ability to define static routes. This was mentioned in issue #920 and is a generalization of use case nb 2.

**Use case 1**
This use case feels different than the other use cases because it only refines one thing, the (primary) scope. The primary scope also happens to be essential to the registration step. So, it seems natural to have this on the register call, via a new option (e.g. strict match vs. prefix). I believe that this was one of the various proposals on the relevant issue.

**Use cases 2, 3 and 4**
On the other hand, use cases 2, 3 and 4 can consist of multiple refinements which are not essential to the registration step and are most likely not critical for the developer (e.g. having a secondary scope fail because a different team has already registered a primary-scoped SW will likely be considered as WAI by the developer).

It seems:
 - logical to do these in the same place as it's ultimately about refining if/how your SW gets involved.
 - natural to use the install event handler to refine a SW's behavior on navigations or sub-resources fetches.
 - ergonomic to have methods that would let developers proceed with one thing at a time. It would let them know which refinement failed and allow them to decide whether to make the install fail or proceed. 

For comparison, if we were to do these refinements as part of the register call, then it seems harder for a developer to reason about why the call failed, or separate the critical from the optional, etc.

Now, I'm not saying that the methods have to be identical - they accept different things after all - but having a similar feel should be possible and welcomed. e.g. re-use the strict match vs. prefix option, parallelism of method names (addScope, addRoute), etc. 

Also, while addressing use case Nb 4 would also cover use case Nb 2, I think we should be able to proceed with an MVP for Nb 2 while keeping in mind the generic use cases in Nb 4.

**Handling scope conflicts** 
Tentative strawman:
 - Secondary scopes must follow the scope rules (e.g. max default scope or max allowed via the Service-Worker-Allowed header)
 - Primary scopes take precedence over secondary scopes.
 - Secondary scopes are first come, first serve.

Does this sound reasonable?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/566#issuecomment-384938199