Re: [w3c/ServiceWorker] Using BroadcastChannel to wake up a service worker (#975)

It seems like any choice here would want to be consistent with the behavior of MessageChannel/MessagePort.  Given the ramifications of the spec for those either trying very hard to avoid making garbage collection visible or eliminate the foot-gun of not holding a strong reference to the MessagePort, I worry that this gets messy quickly and encourages falling into the trap of using a ServiceWorker like it's a SharedWorker.  And at the July F2F I felt like there was agreement that explicit SharedWorkers were far better than never-dying ServiceWorkers, even if some engines need to add them (back).

I could see it being reasonable in the FAQ to have:
* Q: How do I use ServiceWorkers with BroadcastChannels/MessageChannels?
* A: You want to use a SharedWorker.  ServiceWorkers only live long enough to service the ExtendableEvents dispatched to them and then may be terminated.  Your long-lived SharedWorker can interact with the short-lived ServiceWorker as needed.  In exceptional cases, it may make sense to instantiate a MessageChannel for the duration of an ExtendableEvent, but keep in mind that events will eventually be terminated if they take too long.  If your processing may take an unbounded amount of wall-clock time, you will want to move as much of it as possible into the SharedWorker and potentially issue multiple requests to the ServiceWorker.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/975#issuecomment-245960575