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

I would feel more comfortable if we could validate this will work out well with the more complex cases that will arise in the future (scope sets, partial migrations...). In particular, as I asked earlier, do we have a rough understanding on how
> it can be done incrementally on top of this proposal.
Or is it that web locks is supposed to handle these cases, outside of this proposal?

For instance, what is the implication of scope sets to that proposal?
Would we make it mandatory to provide an id if passing a scope set to register?
If so, it seems that we are trying to define a scope name, like we have cache names.

> postMessage-ing a ServiceWorker which potentially could bring both processes and threads into existence and involve evaluating megabytes of JS to avoid exposing a string identifier seems like a bad battery trade-off?

This could be optimised, say service worker at install time adds its scope and version in some database.
The point is whether service workers are doing this sort of management, and if so, how they are doing it, for what purposes...
Then we can validate whether ID is the right tool.

> Cache API cache names, IDB database names, `<element id="foo">`, css class names,

In terms of terminology, it seems that name is a tad better than ID here.
There is a uniqueness to the term ID (like in ServiceWorkerClient.id) which does not really seem guaranteed here.
It is also somehow more consistent with Caches and IDB.

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