RE: A small proposal to cleanup DataChannel construction.

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

------------------------------------------------------------------------------------------------------------------------
From: Justin Uberti [mailto:juberti@google.com]
Sent: Tuesday, April 22, 2014 1:51 PM
To: Robin Raymond
Cc: Peter Thatcher; public-ortc@w3.org
Subject: Re: A small proposal to cleanup DataChannel construction.

Anything specific in mind? If we feel the parameters are too closely coupled to SCTP, I would prefer to try to abstract them so that app developers can be agnostic to the underlying transport.

On Tue, Apr 22, 2014 at 10:50 AM, Robin Raymond <robin@hookflash.com<mailto:robin@hookflash.com>> wrote:

I like but the only issue I have is that RTCDataChannelParameters needs to be abstracted and there needs to be RTCSctpDataChannelParameters derived from RTCDataChannelParameters . Many of the options within "RTCSctpDataChannelParameters" will not necessarily make sense for alternative transport types with alternative optional "RTCDataChannelParameters " values for that transport type. We can put common things like "ID" in a base RTCDataChannelParameters .

Does WebIDL allow downcasting of dictionaries or does RTCDataChannelParameters need to be an interface to support downcasting? I know WebIDL allows dictionary inheritance and upcasting is clear because of the example for WebIDL dictionaries, but downcasting is not clearly defined.

-Robin



[cid:image001.jpg@01CF5E34.E539BB30]
Peter Thatcher<mailto:pthatcher@google.com>
April 15, 2014 at 1:04 PM
I've noticed that createDataChannel and the RTCDataChannel contructor overlap in functionality.  And since almost all of the current API is based around using constructors instead of factory methods, I think we can cleanup the overlap and make it consistent with the rest of the API by doing the following:

[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 {

}


interface RTCSctpTransport : RTCDataTransport {

 // ...
}