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

Re: WebRTC Data Channel in Workers Proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 26 May 2015 21:53:19 +0200
Message-ID: <5564CF2F.6090907@alvestrand.no>
To: public-webrtc@w3.org

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.

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?

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 19:53:51 UTC

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