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

> > Do we have an existing API that follows this mixed pattern?
> 
> `<element id="foo">` is an optional identifier.

If web app does not provide the identifier, the element is not in the map.
The user agent will not generate an identifier to put the element in the map.

> Allowing the developer to provide a meaningful product name like "my-product-foo" is going to be a lot more ergonomic.

Let's get back to your first example.
A first service worker was registered with: sw1 = await navigation.serviceWorker.register('sw.js', {  scope: '/product/bar' });
Then the web app wants to move the scope to 'product'.
The idea would be to do the following: sw2 = await navigation.serviceWorker.register('sw.js', {  scope: '/product', id: '/product/bar' });
In terms of ergonomic, this does not look great: sw2 ID would be '/product/bar' which is potentially no longer meaningful.

The same argument applies if we try to sneak version info in the IDs. If a web app uses 'product-v1' and wants to go to 'product-v2', how can the web app do without removing the 'product-v1' registration?

Another point related to the versioning use case.
As part of the storage spec, there are ideas around grouping resources in a bag (IDB, cache, multiple service worker registrations potentially). It seems that web app provided names for those bags might be a better fit than immutable IDs tied to a registration.

Also, from a readability point of view, using 'id' in the register method does not make it clear at all that sw2 is 'replacing' sw1.
A more explicit syntax might actually be more ergonomic.

> Also, the id makes it clear we are modifying a single registration and not creating a new registration to replace an old one. This is important when you consider other state that sits in managers (push, nav preload, etc) attached to the registration. We don't want to lose all that when the scope changes.

Agreed we do not want automatic dropping of managers.
It seems this can be resolved with or without IDs though. Or am I too optimistic?
If registering sw2 does remove sw1, we could spec that all managers attached to sw1 are moved to sw2.
This might require service worker registrations to have a 'manager list' slot.

Another aspect that does not look great with the ID proposal is that it makes it easy to 'replace' one existing registration but not two existing registrations.
If we think a web site might want to replace '/product/bar' by 'product', it seems very natural that a website might want to replace two registrations ('product/bar' and 'product/foo') by a single 'product' registration.

If we introduce a way for one service worker registration to lock another job queue, this paves the way for multiple registration removal support, should we feel the need.
This locking does not look like something impossible to specify and implement.
I might be too optimistic again, let me know.
For web developers, I do not see the complexity that this proposal will bring.

> Finally, I think its just bad design to allow mutation of the scope on a registration and also try to keep using the scope as a key. How is the spec supposed to sanely deal with a registration where the active worker is scope A and the installing worker is for scope B? We need a stable, immutable key.

It is not yet clear to me whether we want to mutate scopes of a registration or whether we want to easily replace some registrations by a new registration.
In terms of spec editing, is the following feasible?
- Update the spec to move the job queue to the service worker registration
- Allow the scope to registration map to have multiple keys pointing to the same registration

I am not against IDs per se.
So far, I haven't seen a feature that can be implemented by introducing IDs but not without it.
The main advantage might be web developers ergonomics but I would like to be sure that IDs will deliver that in practice.

-- 
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-711145700