A small proposal to cleanup DataChannel construction #60

aboba opened this Issue Apr 15, 2014 · 1 comment


None yet

2 participants

aboba commented Apr 15, 2014

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 commented Apr 25, 2014

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 {

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

@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Apr 29, 2014
Robin Raymond - Fixes for error handling, as described in w3c#26
- Support for contributing sources removed (re-classified as a 1.2 feature), as described in w3c#27
- Cleanup of DataChannel construction, as described in w3c#60
- Separate proposal on simulcast/layering, as described in w3c#61
- Separate proposal on quality, as described in w3c#62
- Fix for TCP candidate type, as described in w3c#63
- Fix to the fingerprint attribute, as described in w3c#64
- Fix to RTCRtpFeatures, as described in w3c#65
- Support for retrieval of remote certificates, as described in w3c#67
- Support for ICE error handling, described in w3c#68
- Support for Data Channel send rate control, as described in w3c#69
- Support for capabilities and settings, as described in w3c#70
- Removal of duplicate RTCRtpListener functionality, as described in w3c#71
- ICE gathering state added, as described in w3c#72
- Removed ICE role from the ICE transport constructor, as described in w3c#73
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment