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

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

Moving from a sub-product up to a top level product is not something I've heard any developers tell me they want to do.  But even, so the fact that they *could* do this if the need arose is a feature.  The fact that the name becomes sub-optimal should not prevent us from supporting the other more common use cases.  In the more general case, I don't think the browser should say developers can't name things because they might choose bad names.

> Update the spec to move the job queue to the service worker registration

Taking stateful things that used to have an immutable relation with a registration and now allowing them to move seems to add a lot of complexity.  In particular, you would have to move the job queue while you are in the middle of a job running from that queue.  This does not seem like a good design option to me.

> Allow the scope to registration map to have multiple keys pointing to the same registration

I'm not sure how this helps to be honest.  I guess you are saying allow "old scope" and "new scope" to point to the same registration for some time?  I think the complexity comes from when "old scope" stops working and how to handle that transition without edge cases.  That problem seems to persist regardless of how long you delay dropping the "old scope".

Maybe it would be possible to make these work with a lot of effort, but the cost benefit does not seem to make sense to me.  Identifier/name values are such a common, simple thing in web APIs already and would be relatively straightforward to add here.

Anyway, if there is time I'd like to discuss this proposal at one of the TPAC meetings this being discussed in #1536.

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