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

> On 9 Apr 2018, at 19:04, youenn fablet <yfablet@apple.com> wrote:
> 
> I would favor enabling instantiations of PeerConnection in workers.
> It seems particularly useful in ServiceWorker contexts where the link with a particular Document may be broken at any point.
> If we have that, there might be little incentive in transferring data channels.

That would be nice, but there are a bunch of user interaction requirements that may make that tricky,
- Getting local IP addresses requires a user to grant media permissions.
- Authenticating an ID requires a user interface 
- starting a media stream requires a user click

That’s just off the top of my head. I suspect more would be found if one looked hard.

I have the feeling that transferring a connected DataChannel over a postMessage may be
more of a quick win.

T.


>     Y
> 
>> On Apr 9, 2018, at 6:54 AM, Randell Jesup <randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>> wrote:
>> 
>> 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> <mailto: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 <mailto:randell-ietf@jesup.org>!  Way too much spam
>