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

What is a "scope set"?  Do you mean the list from the scope pattern effort?  If so, my current plan is the id value would get the serialized string form of the scope pattern, whether its a list or not.  Since that work is not finalized I don't have a finalized serialization.  I don't see why that should stop the addition of an id, though.

We could also make an id mandatory for new scope pattern or pattern list uses.  There is no backward compat issues to deal with there since its a new feature.  I don't have a strong preference on that vs stringifying the scope pattern.

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

I don't care if we call this a `name` vs an `id`.  I will note, though, it *is* required to be unique.  You cannot have two registrations with the same "name" at the same time.

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

I still don't fully understand what use cases you are exactly trying to cover.  The more clearly you define those the better I can address them.

Speaking to the possible "many-to-one" registration convergence case we discussed above I've already briefly mentioned on incremental approach:

```javascript
navigator.serviceWorker.register(script, {
  id: 'foo',
  scopePattern: patternList,
  replaceConflicts: true // replace any conflicting registrations
});
```

Or we could make it more explicit:

```javascript
navigator.serviceWorker.register(script, {
  id: 'foo',
  scopePattern: patternList,
  unregister: { sw_id_1, sw_id_2, sw_id_3 }  // remove other registrations we are replacing
});
```

Or we could create a separate function like you proposed above, but it would take id's instead of scopes:

```javascript
navigator.serviceWorker.updateScopes({sw1: sw_id_1, sw2: sw_id_2, ...})
```

Again, I don't think we have justification to pay the complexity cost for any of these solutions yet.  However, I really don't see any limitations imposed by having a name/id to reference registrations.

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