new ServiceWorkerClient makes no sense?

[annevk]

So the idea is that new ServiceWorkerClient instantiates a new Window. However, a Client represents both a Window and a WorkerGlobalScope. This needs to be done some other way I think.

[KenjiBaheux]

Note: ServiceWorkerClient's constructor is currently out of scope for blink.

[jakearchibald]

@annevk I'm trying to make the constructor useful & avoid the "secret token" stuff.

There could be an option bag with a 'type' property that allows it to be a document/sharedworker. If you try and construct a new sharedworker client, it throws. I suppose that's kinda reintroducing the "secret token" thing, but at least the default would be document & new ServiceWorkerClient would work.

[annevk]

Workers already have (remote) constructors. new Worker and new SharedWorker. Perhaps this should be new BrowsingContext and clients should return references to Worker/SharedWorker/BrowsingContext. That'd make some amount of sense. (Perhaps we want to rename clients to environments, as that's the term we use for these things more or less.)

[jakearchibald]

I'm nervous about fetchEvent.client (or wherever it ends up) being a different kind of object sometimes. Same goes for items returned by .getAll.

The getAll case worries me more, because I can imagine code that "works fine" and then fails down when workers end up in that list. We could fix that by only returning BrowsingContexts unless an option is set (we already have an option for uncontrolled clients).

I'll go with that unless my brain surprises me with a better idea.

[annevk]

Can't we make sure the objects look roughly similar? After all, it seems like these objects should look roughly similar.

[jungkees]

I believe we've been discussing through it and sorted out the issue. For the original question here, we provide clients.openWindow(url). Closing.