W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: WebRTC Data Channel in Workers Proposal

From: Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
Date: Tue, 26 May 2015 20:08:11 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <D18A9C8B.15210%goran.ap.eriksson@ericsson.com>

>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
>> Service Worker is good to have before taking the next step towards also
>> exposing the Data Channel in a Service Worker-Œsh like worker.
>> 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC