Consider merging transferable RTCDataChannel from webrtc-extensions

[tguilbert-google]

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.

[dontcallmedom]

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?

[alvestrand]

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.

[dontcallmedom]

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.

[tguilbert-google]

[...] 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.

[alvestrand]

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.

[youennf]

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.

[alvestrand]

@youennf can you add some of those scenarios to webrtc-nv-use-cases?

[youennf]

https://www.w3.org/TR/webrtc-nv-use-cases/#decent already covers some of those scenarios (P2P and service workers).