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>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]
> Sent: Tuesday, April 15, 2014 10:04 AM
> To: 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).
>
>