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

> A website can get the registration for a given scope, post message to the corresponding service worker which will post message back its version. For instance, the version value could be baked into JS script, which might be handy to handle DOM cache versioning.

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?  Especially if such an idiom might result in a page postMesssaging potentially N registrations for its whole origin?

> I am not sure how a web site can be sure that an ID it gave to register will exactly refer to the registration object the page is thinking of in multi-process architectures? Say we get registration.id and plan to use it, but take enough time that another page uses to unregister/register registrations with the same ID.

My understanding of the proposal was that basically everything that is currently "scope to FOO map" becomes "id to FOO map".  So the existing [scope to job queue map](https://w3c.github.io/ServiceWorker/#dfn-scope-to-job-queue-map) and its ordering guarantees and coalescing and idempotency semantics will be maintained.  When coordination that exceeds this weak ordering mechanism is required, there's https://wicg.github.io/web-locks/ (which Firefox intends to implement).

> Do IDs need to be given by web pages? Can/should they be generated by the user agent?

I believe the prior suggestion was to default to using the scope as the id if not explicitly specified, which seems reasonable and equivalent to current behavior.

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