Open tguilbert-google opened 4 weeks ago
re ServiceWorker
, is the lack of implementation of that part in Chromium based on opposition to including it, or is that part of a later iteration?
I don't think we have any commitment to transfer to a non-dedicated worker. It would be nice to have it work anywhere, but I suspect that we will have more difficulty for datachannels that are not within an agent cluster. @tguilbert-google can probably give a clearer answer.
if so, this would suggest integrating the changes in webrtc-extensions limiting it to DedicatedWorker
, and leaving the more generic Worker
in webrtc-extensions for future consideration.
[...] but I suspect that we will have more difficulty for datachannels that are not within an agent cluster.
Indeed, supporting DedicatedWorkers
was a low hanging fruit, whereas supporting ServiceWorkers
would require some serious re-architecturing, and we can't commit to supporting it at this moment.
As a side note: a peerconnection
is not transferrable and closes all of its RTCDataChannels
when it closes. Does this limit the usefulness of transferring RTCDataChannels
to ServiceWorker
, since their lifetime is still tied to the Window
that originated them?
Integrating DedicatedWorker
only for now sounds like a good plan.
The discussions we've had about PeerConnection indicate that there's some interest in making PeerConnection available in a worker, but that the cognitive and implementation problems of making it transferable were more trouble than it was worth - PeerConnection's purpose is being connected, and what happens to those connections during a transfer is going to be hard to specify.
Implementation-wise, the "real" PeerConnection lives on a separate thread in the agent cluster's memory space - so communicating between the transferred RTCDataChannels and the PeerConnection background object is relatively simple, but switching that to a cross-memory-space mechanism would be both quite complex and performance-impacting.
I do not think the issue is service worker vs dedicated worker but out-of-agent-cluster transfer, which can happen when transferring from a window to another window/dedicated worker/service worker/shared worker.
My guess is that Chromium current implementation will initially be limited to transfer to same-agent cluster. AFAIK, supporting same-agent cluster transfer is covering the most pressing needs but we identified in the past scenarios where out-of-agent-cluster transfer would be useful too.
@youennf can you add some of those scenarios to webrtc-nv-use-cases?
https://www.w3.org/TR/webrtc-nv-use-cases/#decent already covers some of those scenarios (P2P and service workers).
The WebRTC-extension spec has a Transferable RTCDataChannel section.
WebKit has been shipping this feature for a while now. Chromium is projected to be shipping it in M130.
Should the text of the
webrtc-extensions
spec be merged back into the main spec? It might fit the merge criteria at this point.One point that might need additional discussion: WebKit allows transfers to DedicatedWorkers and ServiceWorkers, whereas Chromium supports transfers to DedicatedWorkers.