Re: WebRTC in workers

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.

Feross

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>
wrote:

> 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.
>
>
>