Re: [ServiceWorker] Worker-As-A-Service service workers (#744)

I don't think you'd need either navigator.connect or foreign fetch for this usecase. Nothing stops you from having arbitrary many service worker registrations at arbitrary scopes (using the scope solely as an identifier for a particular worker). The existing navigator.serviceWorker.getRegistration API allows you to look up a registration by that identifier, and you can then use the existing postMessage API to communicate between the multiple service workers.

Of course as you point out that still leaves the versioning and synchronized update problem, and maybe sometimes you really do need to run tasks that last longer than a service worker is allowed to run.

Maybe some way shared workers could be made to work is to tie its lifetime to some new kind of UI surface like system tray icons or maybe even better notifications with progress indicators? Allowing service workers to spawn workers that can continue to work even after the service worker (and any clients/UI surfaces) have been closed doesn't seem like the best idea, but if there is at least some UI that shows the user that some background work is being done, that might be enough?

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