Re: A small proposal to cleanup DataChannel construction.

Robin said: 

I suggest we "borrow" the parameter definition 'as is' unless there's reason to not do it.
​
[Peter] I agree.  Isn't that what we've done already?​

[RR] We did, but perhaps it's from an older spec. We had odd things in ours like "preset" and "stream". So I was puzzled.

[BA] I'm puzzled too.  If we were to "borrow" the parameter definition from WebRTC 1.0 'as is', and allow some of the attributes to be nullable, I believe this is what we would have: 

dictionary RTCDataChannelParameters {
    boolean         ordered=true;
    unsigned short? maxPacketLifetime = null;
    unsigned short? maxRetransmits = null;
    DOMString?     protocol = "";
    boolean?          negotiated = false;
    unsigned short?  id = null; 
};

Are we missing anything important?  Note that the original constructor in the Editor's draft looked like this: 

[Constructor(RTCSctpTransport transport, DOMString id, optional DOMString dataChannelType)]
interface RTCDataChannel : EventTarget {
    readonly    attribute RTCSctpTransport transport;
    readonly    attribute DOMString        id;
    readonly    attribute DOMString        type;
    void send (Object data);
                attribute EventHandler     ondata;
};

[BA] Can someone explain what dataChannelType is?  The definition in the Editor's draft is unclear. 

Also, the WebRTC 1.0 interface looks like this: 

interface RTCDataChannel : EventTarget {
    readonly    attribute DOMString           label;
    readonly    attribute boolean             ordered;
    readonly    attribute unsigned?           maxPacketLifeTime;
    readonly    attribute unsigned?           maxRetransmits;
    readonly    attribute DOMString           protocol;
    readonly    attribute boolean             negotiated;
    readonly    attribute unsigned short      id;
    readonly    attribute RTCDataChannelState readyState;
    readonly    attribute unsigned long       bufferedAmount;
                attribute EventHandler        onopen;
                attribute EventHandler        onerror;
                attribute EventHandler        onclose;
    void close ();
                attribute EventHandler        onmessage;
                attribute DOMString           binaryType;
    void send (DOMString data);
    void send (Blob data);
    void send (ArrayBuffer data);
    void send (ArrayBufferView data);
};

[BA]  Comparing this against the interfaces below, it appears that we are missing the label attribute as well as binaryType and the RTCDataChannelState (is this handled by the RTCDtlsTransportState?).  

For reference, the rest of the proposal 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;
};

interface RTCDataTransport {
};

[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;
};

Received on Thursday, 24 April 2014 05:12:13 UTC