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

Currently registrations are identified and keyed based on their scope string.  This works well for most cases, but can create difficulties for folks that want to modify the structure of their site.

For example, consider a site that has a product hosted at a location like:

  foo.com/product/bar

But they want to re-organize their site to remove the "/product" sub-path since its needlessly verbose.  They want to move to:

  foo.com/bar

In this case they must unregister their old scope and register their new scope.  Both the removal of the old registration and the installation of the new registration are async operations that can take time to complete.  In addition, both of these service workers may wish to manage the same underlying resources.  Trying to coordinate between the service workers to avoid accidentally breaking something can be difficult.

As an alternative, we could allow the service worker to specify a separate origin-unique identifier.  For example:

```
await navigation.serviceWorker.register('sw.js', {
  scope: '/product/bar',
  id: 'product-bar',
});
```

Then when the site registers a service worker on a different scope with the same `id`, it would be treated as an update of the service worker that modifies the scope.

While there are uses for this today, this sort of thing may be a lot more useful in a world where the [scopes pattern matching](https://github.com/wanderview/service-worker-scope-pattern-matching/blob/master/explainer.md) has been implemented.  With the scopes pattern matching sites may want to mutate their scope pattern over time to cover more sites or to fix mistakes in the pattern, etc.

Note, there is also an effort to add a unique identifier to manifests for webapps in w3c/manifest#586.  I asked if they wanted to try to unify with service workers, but the feedback was that they should be separate.

The manifest issue also suggests the identifier should be a URL instead of an opaque string.  I don't have a strong feeling about, although I feel it might confuse people into thinking it somehow operates as a scope.

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