Re: WebRTC in {Web,Shared,Service} Workers

On 4/9/2018 5:32 AM, westhawk wrote:
> This is an important topic - I’d love to have any access to RTCDataChannel in workers - especially service workers….
>
> I believe the current thinking is that defining a safe/relevant/complete subset of RTCPeerConnection
> to allow RTCDataChannel’s to be set up in a worker is a _lot_ of work (especially thinking through the
> security requirements around valid SDP/identity). So the discussion centered on a proposal that seems
> (on the surface) simpler. That is allowing  live RTCDataChannels to be transferred to workers
> with postMessage() in the same way that MessagePorts can.

I would *love* for DataChannels to be available in workers; that was 
something we identified as a goal a long time ago.  Also, we discussed 
making MediaStreams transferrable.

Because DataChannels are inherently disconnected from all the media 
issues, and do little beyond send() and received a small number of 
events and support a few status properties, this is quite doable. 
Probably the hardest part is speccing out the interactions between the 
PeerConnection owned by a document, and the DataChannel being operated 
on in the worker, and the timing issues associated with this.  For 
example, a worker wouldn't be able to call createDataChannel directly 
(since it's done on the PeerConnection). But I think that's ok.  
Anything that closes the PeerConnection would cause the DataChannel's 
onclose to fire, of course, and that has to route across to the worker, 
so some additional bookkeeping would be needed, and it also will make 
anything that tracks all the active datachannels more interesting, since 
if it's transferred, and then closed in the worker, anything in the 
mainthread DOM that was trying to watch for things like close events 
will miss it, of course.  Again, I think that's ok.

I agree that transferring PeerConnections is much more complex - useful, 
for sure, but a much bigger set of work to do in both spec and 
implementation.   It would probably be simpler (though still significant 
work) to spec creation and use of a PeerConnection from within a worker.

>> On 8 Apr 2018, at 18:13, Isaac Kwan <i@isaac.pw> wrote:
>>
>> I am aware that there has been discussions in the mailing list and
>> GitHub on this, and that I probably are over-simplifying it, but is
>> there a reason why we can't expose RTCDataChannel etc to workers?
>>
>> This does not involve transferring ownership of existing connection
>> from other scopes, connections are set up in the worker and ends
>> "automatically" when it goes out of scope (e.g. exceeds the service
>> worker timeout limit).


-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org!  Way too much spam