Re: [webrtc-pc] Add support for WebRTC Data Channel in Workers (#230)

An implementation of a fix to this issue would be making *just* RTCDataChannel available in *just* (ordinary, Web, non-Service) Workers, right? Along the lines of #317 or #445, you would be able to send an already open RTCDataChannel to a Web Worker, but a Web Worker would not be able to open any new connections (because of not having RTCPeerConnection) and a Service Worker wouldn't be able to use either. (As pointed out [here](https://github.com/w3c/webrtc-pc/pull/317#issuecomment-170763447) by @martinthomson, a Service Worker is supposed to only be spun up for a few seconds at a time to handle a request, and giving it a peer to peer connection causes trouble with that model that people did not want to solve at the time.)

I'm not sure a fix to this issue would then really provide what @jimmywarting, @nkev, and others are asking for, which is a way to host a useful peer-to-peer node in a browser in the background (or at least independent of any single tab), in a context where it can idiomatically service requests.

I'm going to open an issue to track providing the whole WebRTC API to all types of workers (including Service Workers) in a way that is useful for p2p content distribution but which doesn't buy you infinite service worker runtime for every site the user ever visits. Actually fixing that bigger issue is where a lot of the hardness is, it seems, and probably shouldn't block a fix for this issue for whoever actually needs exactly the functionality of shipping an RTCDataChannel specifically to a Web Worker specifically.

-- 
GitHub Notification of comment by interfect
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/230#issuecomment-655242690 using your GitHub account

Received on Wednesday, 8 July 2020 02:26:45 UTC