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

> xref #1331 and in particular Asa's comment [#1331 (comment)](https://github.com/w3c/ServiceWorker/issues/1331#issuecomment-403575004) which cited latencies of up to 1 second with IndexedDB. Also xref #1157

This comment was done 2 years ago. Since then, I know some implementation efforts have been made to speed up IDB.
Are we sure this still holds true? Is DOM Cache suffering from the same issue?

> my current plan is the id value would get the serialized string form of the scope pattern, whether its a list or not

This seems like a good plan, good enough that web developers might not feel the need to set IDs very often.
They might actually never want to do it in the context of the migration problem we want to solve.

For instance, if we take your example, we could pass scopes instead of IDs:
navigator.serviceWorker.register(script, {
  scopesToRemove: ['foo/product',...],
  scope: 'foo',
});
What is the advantage of passing an ID instead of a scope?

Another possibility is to pass registration objects directly:
navigator.serviceWorker.register(script, {
  registrationsToRemove: [registration1, ...],
  scope: 'foo',
});
The difference between passing strings versus registrations is that the user agent might be able to check that the registration is still in the map when manipulating it. This is not possible with a string. If the registration is not in the map, maybe it is safer to reject?
I am not sure that this additional safety is worth the extra work to get the registration before removing it.
But it seems worth deciding explicitly what we prefer.

One problem I have with the ID proposal is that ID is optional, because we already have scope and scope is mandatory.
For other APIs I know of, either web developer needs to pass IDs or IDs are generated by user agents.
Do we have an existing API that follows this mixed pattern?

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