W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2018

Re: WebRTC in workers

From: Feross Aboukhadijeh <feross@feross.org>
Date: Tue, 26 Jun 2018 16:28:50 -0700
Message-ID: <CA+nRABkNnaqqX3nVmfJGhL64mFagXwmw5vF7kBv-6t_Apes2Ow@mail.gmail.com>
To: harald@alvestrand.no
Cc: public-webrtc@w3.org
Seconding what Youenn said. Transferring a data channel to a worker while
the PeerConnection remains in the main thread would prevent many use cases.
It's best if the PeerConnection can be initiated directly in the worker so
it can be shared among many open tabs, or initiated entirely from within a
service worker in response to a push notification or 'fetch' event.


I write at feross.org and tweet as @feross <https://twitter.com/feross>.
I work on WebTorrent <https://webtorrent.io/>, Standard
<https://standardjs.com/>, and Study Notes <https://www.apstudynotes.org/>.

On Fri, Jun 22, 2018 at 10:49 PM Harald Alvestrand <harald@alvestrand.no>

> On 06/23/2018 02:20 AM, youenn fablet wrote:
> > This does not cover the case of long lasting connections in
> shared/service workers: closing the peer connection window would close the
> data channel.
> > Note also that transferring a RTCDataChannel between different contexts
> is already shimable using postMessage.
> >
> Are you thinking of transferring a shim that uses postMessage to deliver
> the objects to be sent back to the context in which the datachannel lives?
> That would work, but it seems to me it would have a bit of overhead
> (both in delay and in cycles).
> --
> Surveillance is pervasive. Go Dark.
Received on Tuesday, 26 June 2018 23:29:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:42 UTC