Re: [w3c/ServiceWorker] consider allowing a non-scope identifier for registrations (#1512)

> What is the use case for this?

I do not have a particular use case. It is just an extrapolation of the use cases you were mentioning.
If we introduce scope lists, this could add further possibilities to migration scenarios.

> But I think we could tackle that by allowing the new registration to simply overwrite old registrations with a "force:true" option or something. That would be much less complex than a general locking mechanism.

Agreed lock/unlock might be too complex. I fear force:true (or other booleans proposed in this issue) might be too restrictive.
I would be happy to be convinced otherwise.

> If we want to allow registrations to change scope, it seems necessary to me for the scope not to be used as the unique identifier for the registration.

As I said earlier, I agree with the idea to relax the relationship between scopes and registrations.
A registration ID for internal management purposes might be fine but I am not sure why we should expose such IDs to web pages. We already have service worker and registration objects for instance.

> > Something like navigator.serviceWorker.updateScopes({sw1: myScope1, sw2: myScope2, ...})
> 
> Can you please elaborate on this? I see you've identified two scopes, but I don't understand what this is supposed to do to the service worker registrations.

Let's say we have two old service workers sw1 and sw2 and want to replace them with a brand new sw3.
const sw1 = await navigator.serviceWorker.register(...);
// wait for sw1 to be activated.
// Atomically change scopes so that sw1 and sw2 will no longer match while sw3 will match both sw1_scope and sw2_scope.
await navigator.serviceWorker.updateScopes({ sw1: null, sw2: null, sw3: ['sw1_scope', 's2_scope']})

A weakness of this proposal is the fact that sw3 would be registered to an initial scope, hence why I was mentioning the idea of an empty scope.

-- 
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/1512#issuecomment-707192942