Serviceworker: Service worker ID - remove?

[jakearchibald]

https://w3c.github.io/ServiceWorker/#dfn-service-worker-id - we don't appear to use this. Does anyone? If not we should remove it.

[wanderview]

We might use it internally, but its probably safe to remove from the spec.

[n8schloss]

This would actually be useful if we could expose it to developers. We need something like this to correctly track upgrades and it's useful to help installing worker not mess with activating workers. Right now we need to do some things to basically fake this, but it's slow so if the browser could just provide developers with the id that it already has that would make things a bit better for developers.

[wanderview]

We used to have the id exposed but removed it in favor of ServiceWorker object equality, if I remember correctly.

[n8schloss]

Hmm, it'd be nice if we could bring it back. There are quite a few use cases that we have for it now. Similarly there's no clean way for a specific service worker to get it's own service worker object which would also make using the id much easier.

[wanderview]

Kind of a tangent, but if we bring this back, it would be nice to align it with Client.id. It should be possible to reference a ServiceWorker global as a Client and ideally the id value would match ServiceWorker.id.

[jakearchibald]

@wanderview that'd be a change from how client ID works now, as the ID wouldn't change between termination & running the next time.

@n8schloss I've generated version IDs using hashes before - https://jakearchibald.com/sw.js. Can you talk a little bit on how an ID is better than this?

[wanderview]

@wanderview that'd be a change from how client ID works now, as the ID wouldn't change between termination & running the next time.

Right. Good point. Carry on.

[n8schloss]

@jakearchibald, that's our current hack here. It works fine, but like @wanderview said, there's an argument to be made that having it allows for a better level of consistency between SWs and Clients. Also, if the browser is already storing an ID like this it wouldn't be much more work to expose it?

Besides that, it really would be nice to have a way for a SW to get it's own ServiceWorker object so it can tell what state it's currently in. I'll file a separate issue for that though.

[jakearchibald]

F2F: We can remove this - #1077 solves the use case.

[jakearchibald]

TODO: remove from spec

[valioDOTch]

So there's no possibility to mention the service worker ID in log entries? :-(
My problem is, that I have lots of debug output for the SWs on the console and it's a rather difficult to identify which line was produced by which worker...