Re: WebRTC Data Channel in Workers Proposal



>
>Another question (showing the depth of my ignorance about exposing APIs):
>
>If we expose an interface to Workers with [Expose=Window, Worker], does
>that mean that all interfaces that it uses will also have to be exposed
>to workers, or are they hidden somehow?
>
>My main concern is that PeerConnection uses the MediaStreamTrack
>interface, which there has been prevoius concerns with exposing due to
>complexity of implementation.

I have had the same concern- this feels like a more complex, therefore
future use case.

>
>If we can expose just the DataChannel object, and send the datachannel
>to workers, I think we have a more manageable first step than if we
>start exposing "everything" - but OTOH, a DataChannel has a strong
>reference to its PeerConnection; how do lifetimes work with objects sent
>between windows and workers?

Well, Yup. Perhaps the 1.0-API has too many such stuff inside. A
“low-level” API as in ORTC and OpenWebRTC could possibly more easily be
evolved to expose something suitable to a SW. At the very least I feel
this is a possible ‘feature’ for [earliest] next version of the WebRTC API.

Perhaps something to have on the TPAC agenda, :-)!

>
>
>Den 26. mai 2015 21:13, skrev Göran Eriksson AP:
>> 
>> 
>>> On 26 May 2015 at 08:08, Feross Aboukhadijeh <feross@feross.org> wrote:
>>>> I would like to propose that we support WebRTC Data Channel in Workers
>>>> (`WebWorker`, `ServiceWorker`, etc.)
>>>
>>>
>>> This proposal needs considerably more substance.  For instance, the
>>> implementation of something like this in a ServiceWorker in particular
>>> is not suited to the lifecycle model of service workers.
>>>
>>> I get the reasons that this is attractive: it's superfiially very
>>> attractive.  But I think that we need to carefully consider how we
>>> move something of this complexity.
>> 
>> 
>> Agreed. This kind of capability is interesting but I can appreciate the
>> complexity.
>> 
>> Personally, I could imagine that some more experience and evolution of
>>the
>> Service Worker is good to have before taking the next step towards also
>> exposing the Data Channel in a Service Worker-Œsh like worker.
>>Personally,
>> I would also prefer to have the Œlow-level¹ API in place before taking
>> this step.
>> 
>>>
>> 
>> 
>

Received on Tuesday, 26 May 2015 20:08:39 UTC