- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 25 Sep 2015 10:56:03 -0700
- To: Randell Jesup <randell-ietf@jesup.org>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
I think that this is a good idea.
The primary change [Transferable] might be easy to do, but I think
that we will want some security considerations. Transferring a socket
to another origin using postMessage() is a non-trivial thing to reason
about.
That said, I think that it's perfectly fine: an origin could easily
accept the messages and forward them individually using postMessage().
On 25 September 2015 at 08:54, Randell Jesup <randell-ietf@jesup.org> wrote:
> Use-case:
> A number of applications using RTCDataChannels would benefit from being able
> to process the data and send data from a Worker. An example of this is a
> game which handles state updates and other processing in a Worker, keeping
> the mainthread application free to handle rendering and UI interactions, and
> avoiding or minimizing GC pauses.
>
> Basic Mechanism:
> The RTCDataChannel would be a transferrable object, which can be sent via
> postMessage:
>
> channel = createDataChannel("MyChannel", {});
> // or we're in an ondatachannel callback/event triggered by the other
> // side creating an RTCDataChannel
> worker.postMessage(channel, [channel]);
> // channel is now owned by the worker; no more events will occur on the
> // sender's version of 'channel'
>
> The worker will receive the object, and can set event handlers on it.
>
> Handling of Events:
> After a transfer, all events occur in the worker, and the worker must set up
> event handlers to process them. Any events that occur during the transfer,
> or that were queued to be fired in the sender, will be held until the worker
> gets the transferred object. This means the worker should set EventHandlers
> on the channel immediately on receiving the channel.
>
> Close:
> The worker can call channel.close(), which will operate normally. If the
> PeerConnection is shut down via peerconnection.close(), or if the
> RTCDataChannel m=application line is renegotiated 'off', then the worker
> will receive a close event for the channel, as normal.
>
> An RTCDataChannel may be transferred at any time, and may be transferred
> more than once.
>
> ToDo: write a PR for the spec. I believe this will be a fairly small change
> to the spec itself (and we've been indicating we want it), so I'd like to
> have this in 1.0.
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
> Please please please don't email randell-ietf@jesup.org! Way too much spam
>
>
Received on Friday, 25 September 2015 17:56:31 UTC