Re: A small proposal to cleanup DataChannel construction.

WebRTC 1.0 which only uses data channel defines the init properties as 
follows:

dictionary RTCDataChannelInit {
   boolean ordered 
<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-ordered> = true;
unsigned short?maxRetransmitTime 
<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-maxRetransmitTime> 
= null;
   unsigned short? maxRetransmits 
<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-maxRetransmits> = 
null;
   DOMString protocol 
<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-protocol> = "";
   boolean negotiated 
<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-negotiated> = false;
   unsigned short? id 
<http://www.w3.org/TR/webrtc/#widl-RTCDataChannelInit-id> = null;
};

I suggest we "borrow" the parameter definition 'as is' unless there's 
reason to not do it.


One area of concern are these two params:

negotiated of type boolean, defaulting to false
    The default value of false tells the user agent to announce the
    channel in-band and instruct the other peer to dispatch a
    corresponding RTCDataChannel
    <http://www.w3.org/TR/webrtc/#idl-def-RTCDataChannel> object. If set
    to true, it is up to the application to negotiate the channel and
    create aRTCDataChannel
    <http://www.w3.org/TR/webrtc/#idl-def-RTCDataChannel> object with
    the same id <http://www.w3.org/TR/webrtc/#dom-datachannel-id> at the
    other peer.

id of type unsigned short, nullable, defaulting to null
    Overrides the default selection of id for this channel.


Do we need/want this feature? I guess one issue is that if both parties 
create "id" with 30 but set negotiated to false, does that mean they get 
the same channel despite the possibility of "ondatachannel" event firing 
because of a creation race condition?

Likewise if a client uses id of "50" and creates a data channel, and 
re-uses the same id of "50" and creates another data channel, do the 
objects points to the same data channel or is that an error? What if a 
pending "ondatachannel" was going to event but we created "50" first? 
This id thing creates a bit of ambiguity in my mind for behavior and it 
needs clear definition.

-Robin
> Bernard Aboba <mailto:Bernard.Aboba@microsoft.com>
> April 22, 2014 at 6:00 PM
> Within the current proposal, the RTCDataChannelParameters dictionary 
> would look like this:
>
> dictionary RTCDataChannelParameters {
> DOMString id = "";
> DOMString type = ""; // Do we still need this?
> boolean outOfOrderAllowed = false;
> unsigned short maxRetransmitTime = null;
> unsigned short maxRetransmitNum = null;
> DOMString protocol = "";
> boolean preset = false;
> unsigned short stream = null;
> };
>
> With dictionary inheritance, it might look like this:
>
> dictionary RTCDataChannelParameters {
> DOMString id = "";
> DOMString type = ""; // Do we still need this?
> };
>
> dictionary RTCSctpDataChannelParameters : RTCDataChannelParameters {
> boolean outOfOrderAllowed = false;
> unsigned short maxRetransmitTime = null;
> unsigned short maxRetransmitNum = null;
> DOMString protocol = "";
> boolean preset = false;
> unsigned short stream = null;
> };
>
> The rest of it looks like this:
>
> [Constructor(RTCDataTransport transport, RTCDataChannelParameters 
> parameters)]
> interface RTCDataChannel : EventTarget {
> readonly attribute RTCDataTransport transport;
> readonly attribute RTCDataChannelParameters parameters;
> void send (Object data);
> attribute EventHandler ondata;
> };
>
> [Constructor(RTCDtlsTransport)]
> interface RTCSctpTransport : RTCDataTransport {
> attribute RTCDtlsTransport transport;
> static RTCSctpCapabilities getCapabilities ();
> void start (RTCSctpCapabilities remoteCaps);
> void stop ();
> attribute EventHandler ondatachannel;
> };
>
> dictionary RTCSctpCapabilities {
> unsigned int maxMessageSize = null;
> };