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

Re: WebRTC in workers

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 27 Jun 2018 11:25:00 +0200
To: public-webrtc@w3.org
Message-ID: <0d7a112e-89a4-7c93-8b7d-eda0c73d1830@alvestrand.no>
On 06/27/2018 01:28 AM, Feross Aboukhadijeh wrote:
> 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'm still curious about exactly what Youenn meant by "transferring a
RTCDataChannel between different contexts is already shimable".

Another thread pointed out that if you're in the same origin (and same
process), pushing media into another page already works.

So we have three possible technical features:

- Making PeerConnections usable in workers
- Moving objects between contexts (making them transferable)
- Allowing access to media from workers (this may have multiple meanings)

I'd like to put those up in a matrix against the use cases, so that we
can see what's required for what.

>
> Feross
>  
> I write at feross.org <https://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 <mailto: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.
>
>

-- 
Surveillance is pervasive. Go Dark.
Received on Wednesday, 27 June 2018 09:25:30 UTC

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