Re: [ServiceWorker] Workers & SharedWorkers within ServiceWorkers (#678)

Thanks for elaborating on the context and answering to the question @jrburke!

Basically, I agree to the point that the service worker's not designed for long-lived tasks and don't want to deviate from its event based reasoning. But no clear idea about what's a better approach either. So just pondering upon many cases.

About your suggestion - supporting shared worker/worker in service workers, it seems it makes sense to use `waitUntil(p)` in the way in your example so the SW won't be killed until it receives the result back from the shared worker. But if devs don't use it in this pattern and there has been no document bound to the shared worker, we cannot guarantee the execution of the background process and the lifetime of both the SW and the shared worker.

For the following case:
> .. that shared worker could be registered as a service worker, that seems fine as long as:

> email-worker.js is guaranteed to stay running if the email app's browser windows somehow have a reference to it, 

The SW may run until `ClientMessageEvent.waitUntil(p)`'s promise settles rather than the document's lifetime. But you can spin up the SW anytime you'd need to by `registration.active.postMessage()`. In this case, the global state should be kept in persistent storage like IndexedDB. Also even when the document is unloaded, the SW can get a reference to it again by the `ClientMessageEvent` object's `e.source` which is either a `WindowClient` or a `Client`. You can communicate to it via `Client.postMessage()` again.

To clarify, we're counting the case where no tabs are alive when a sync event signals to do the background jobs, right?

> and that reference could be acquired while the backgroundsync is waiting to complete (how would that work in the UI window, is that new SharedWorker('email-worker.js') or something else?)

>From the document that registered the SW, you always has a reference to it: [`registration.installing`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-registration-installing-attribute), [`registration.active`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#navigator-service-worker-active), [`navigator.serviceWorker.controller`](https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#service-worker-container-controller-attribute), etc. They're `ServiceWorker` objects and have `postMessage()` to the service worker's global.

FYI. https://github.com/slightlyoff/ServiceWorker/issues/651 discusses another use case that needs longer lifetime of SWs.

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