Re: [ServiceWorker] ServiceWorkerClient to Client (#588)

> These shouldn't be specific to ServiceWorker, and should move into the Fetch spec.

> But this makes sense if we want the ability to open new windows using new Client elsewhere. 

I thought the `ServiceWorkerClient` object would be just an object that captures a service worker's controlled (or can-be-controlled when selected a registration) client (document or worker) for authors to manipulate and communicate with it. And it's not a `fetch` event specific instance either IMO. When other functional events are fired at the service worker, the event listeners would still want to check out the existing windows and workers in the shape of the `ServiceWorkerClient` objects. In that sense, the `ServiceWorkerClient` here should be something that represents the client that interacts with the service worker. I'm not sure if the advantages the generalized `Client` can bring is much bigger and I'm missing that points?

> Why are we trying to squash windows and workers into a single class? visibilityState, focused, frameType, and focus() all seem inapplicable to workers. Seems better to move the rest of the properties to a base class and have a WindowClient, or similar.

We can do subclassing but then we'd have to define `DedicatedWorkerClient` and `SharedWorkerClient` separately as well, and getAll() should resolve with a sequence holding a mix of those different types of objects. Would that be a better design for authors?

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/588#issuecomment-66969281