Re: [w3c/ServiceWorker] Scope matching algorithm breaks sites that don't end in a slash (#1272)

Not sure if sub-origins are a feasible solution to the general problem, as the boundaries a developer might want between Service Workers or pages without a SW don't necessarily match up to origin boundaries.  For example, for whatever reason I might want a separate SW to manage my app preferences page or script resource caching or whatever, but still want it to share storage and permissions access with my main app SW.  (Not to say I'm not a fan of sub-origins, I just don't think they solve this problem in its entirety.)

Regarding solution 3, while I have no opinion on getRegistration() behavior, could one solution to two SWs trying to register for the same scope simply be that the install of the second fails with a clear and descriptive error?  So long as the additional scopes are defined in register and not onactivate that seems like a straightforward and reasonably practical solution.  

Really good point about migrating a scope between SWs - we didn't consider that.  When we install a SW and give it a cache expry date does it automatically unregister from its scopes once its cache TTL expires?  If so then we may be ok, and I think a reasonable story for migrating a scope such as /login from SW A to SW B would be something like:
1) A site adds code to register SW A with a 1 week expiration date, claiming both "/" and "/login".
2) time passes, people want to split "/login" into its own SW.
3) "/" changes its register call to only register for "/" (exact match) and no longer "/login"
4) "/login" adds code to install SW B scoped for its own path
5) over the course of a week, some of the SW B installs fail because A still has the scope, but by the end of the week all the old As have either been re-registered or have expired from the cache, so Bs all register successfully and all users are in a good state.
Does this make sense?

Problem 3 seems like a very hard problem.  Not sure how to solve it cleanly without something like the conceptual inverse of sub-origins, where two domains can claim to be actually the same and share resources and the like, which mildly terrifies me.  We've been thinking about options like a long-term cached page that is just a full-screen iframe to a canonical origin, though that has obvious latency issues.  Given the difficulties here it's not clear it makes sense to tie solving this problem to solving the other problems and it might be better to consider it separately.

-- 
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/1272#issuecomment-365441981