- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 26 May 2015 21:53:19 +0200
- 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