A small proposal to cleanup DataChannel construction

[aboba]

From: Peter Thatcher pthatcher@google.com
Date: Tue, 15 Apr 2014 10:04:54 -0700
Message-ID: CAJrXDUFaEUBx5ezDJ4M5gsoFg7gYRpWqA4JRUmD-=TLVv-Ovmw@mail.gmail.com
To: "public-ortc@w3.org" public-ortc@w3.org
URL: http://lists.w3.org/Archives/Public/public-ortc/2014Apr/0062.html

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).

[aboba]

Looking over the RTCDataChannel interface and comparing this against WebRTC 1.0, there are a bunch of differences whose justifications aren't clear to me. As an example, the Editor's draft didn't include the readyState, bufferedAmount and binaryType attributes, nor did it include several of the EventHandlers, such as onerror.

To improve compatibility with WebRTC 1.0, I'd like to propose that we keep many of the WebRTC 1.0 constructs, while at the same time incorporating Peter's suggestions. Here is what things would look like:

[Constructor(RTCDataTransport transport, RTCDataChannelParameters parameters)]
interface RTCDataChannel : EventTarget {
readonly attribute RTCDataTransport transport;
readonly attribute RTCDataChannelParameters parameters;
readonly attribute RTCDataChannelState readyState;
readonly attribute unsigned long bufferedAmount;
attribute DOMString binaryType;
void close ();
void send (Object data);
attribute EventHandler onopen;
attribute EventHandler onerror;
attribute EventHandler onclose;
attribute EventHandler onmessage;
};

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

interface RTCDataTransport {
};

enum RTCDataChannelState {
"connecting",
"open",
"closing",
"closed"
};

[Constructor(RTCDtlsTransport)]
interface RTCSctpTransport : RTCDataTransport {
attribute RTCDtlsTransport transport;
static RTCSctpCapabilities getCapabilities ();
void start (RTCSctpCapabilities remoteCaps);
void stop ();
attribute EventHandler ondatachannel;
};

One more thing: In WebRTC 1.0, (see http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcdatachannel) send is defined as follows:

void send (DOMString data);
void send (Blob data);
void send (ArrayBuffer data);
void send (ArrayBufferView data);

Is there a good reason why we need to do things differently in ORTC API? And yes, I agree that this is handled more cleanly in the Editor's draft and that the above is clumsy, but...