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

@jungkees for the email app, it wants to use a shared worker to hold the data layer and convert network fetches to JS objects used by the data layer, and all UI windows talk to this shared worker to get data for its views. That shared worker should live as long as the UI windows live, and be possible to spin it up from the UI windows.

That model would be used even without service workers in play. The user can manually trigger syncs in the UI via a button. Now with service workers we have an automated entry point for backgroundsync and we just want to hand off to that shared worker, which already has all the smarts to do the syncing.

If you are suggesting that the shared worker, email-worker.js, could implement the service worker entry point for backgroundsync and 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, 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?)
* the email app could still use a separate service worker to handle fetches for its UI resources.

My impression is that the service worker is not long-lived enough to be able to also function in the same role as our shared worker, and it was actually desirable to make sure the service worker did not do too much to limit its scope and purpose. However if that is not true, then it would be great to walk through a more thorough code example that demonstrates how that would work.

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