RE: A small proposal to cleanup DataChannel construction.

Yes, that is where they should go.

From: Peter Thatcher [mailto:pthatcher@google.com]
Sent: Wednesday, April 16, 2014 2:57 PM
To: Bernard Aboba
Cc: public-ortc@w3.org
Subject: Re: A small proposal to cleanup DataChannel construction.

Shouldn't those both be in RTCDataChannelParameters?  I thought they already were.  I must have missed that.

On Wed, Apr 16, 2014 at 2:42 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
A question:  do the following attributes formerly in the RTCDataChannel interface (and constructor) vanish, or do they now show up somewhere else?

    readonly    attribute DOMString        id;
    readonly    attribute DOMString        type;
________________________________________
From: Peter Thatcher [pthatcher@google.com<mailto:pthatcher@google.com>]
Sent: Tuesday, April 15, 2014 10:04 AM
To: public-ortc@w3.org<mailto:public-ortc@w3.org>
Subject: A small proposal to cleanup DataChannel construction.

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 {

 // ...

}


The difference is basically that:
1. We no longer have a createDataChannel method, and just call the constructor instead.
2. RTCDataChannel no longer relies directly on SctpTransport. In the future, we could have a different kind of DataTransport and have DataChannels that work with it (we aren't as tightly coupled to SCTP).