W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2014

Re: Improvements suggestion for DataChannels

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 14 Jan 2014 08:29:04 +0100
Message-ID: <52D4E740.2080507@ericsson.com>
To: "piranna@gmail.com" <piranna@gmail.com>
CC: public-webrtc <public-webrtc@w3.org>, Luis López Fernández <luis.lopez@urjc.es>
On 2014-01-13 22:28, piranna@gmail.com wrote:
>>> (third bullet) I would suggest using the open event on the creating side for
>>> this. You get the channel from the target property of the event, and the
>>> channel is in the open state; same state as in the "datachannel" event
>>> handler on the receiving side.
>>>
> I've re-read about this point on the latest specification (10
> September 2013) and if I understood it correctly, it's not defined to
> work as you said:
>
> "
> A RTCDataChannel, created with createDataChannel() or dispatched via a
> RTCDataChannelEvent, MUST initially be in the connecting state. When
> the RTCDataChannel object’s underlying data transport is ready, the
> user agent MUST announce the RTCDataChannel as open.
>
> When the user agent is to announce a RTCDataChannel as open, the user
> agent MUST queue a task to run the following steps:
>
> If the associated RTCPeerConnection object's RTCPeerConnection
> signalingState is closed, abort these steps.
>
> Let channel be the RTCDataChannel object to be announced.
>
> Set channel's readyState attribute to open.
>
> Fire a simple event named open at channel.
>
> When an underlying data transport is to be announced (the other peer
> created a channel with negotiated unset or set to false), the user
> agent of the peer that did not initiate the creation process MUST
> queue a task to run the following steps:
>
> If the associated RTCPeerConnection object's RTCPeerConnection
> signalingState is closed, abort these steps.
>
> Let channel be a newly created RTCDataChannel object.
>
> Let configuration be an information bundle received from the other
> peer as a part of the process to establish the underlying data channel
> described by the WebRTC DataChannel Protocol specification.
>
> Initialize channel's label, ordered, maxRetransmitTime,
> maxRetransmits, protocol, negotiated and id attributes to their
> corresponding values in configuration.
>
> Set channel's readyState attribute to connecting.
>
> Fire a datachannel event named datachannel with channel at the
> RTCPeerConnection object.
> "
>
> If I understood it correctly, 'datachannel' event is dispatched on the
> receiver endpoint to notify that a new DataChannel has been created,
> but it's on the 'connecting' state, not the 'open' one, and that the
> 'open' event should be dispatched on both endpoints (starter and
> receiver) when the connection is ready and not only on the starter
> one. Is it correct? If so, I don't see any problem to also dispatch
> the PeerConnection 'datachannel' event on the starter endpoint, since
> definitely it's not doing the same task that the DataChannel 'open'
> one...

Your interpretation is correct. We switched to the "open on both sides" 
approach a while ago.

But then there you have your symmetric event; if you need to do similar 
work on both sides as the result of a event, can't you use the open 
event? Generally it's much more convenient to work with synchronous APIs 
than with events and callbacks. Since createDataChannel() is a factory 
method that can be synchronous, I think it's more intuitive to keep it 
like that.

/Adam
Received on Tuesday, 14 January 2014 07:29:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:37 UTC