- 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