Re: [rtcweb] DataChannels API and external negotiation

On 4/1/2013 12:48 PM, Martin Thomson wrote:
> This looks fine, but I'd like to bike shed just a little.
> On 31 March 2013 19:29, Randell Jesup <> wrote:
>> Here's a proposed API for DataChannels with external negotiation, per the
>> recent Interim and IETF meeting (most of this was in my previous W3 email,
>> but I've added info on when 'stream' is valid to read, and how even/odd
>> roles are assigned for the IETF protocol). I'll note for the IETF folks that
>> 'protocol' is in a JS dictionary object in this update, which avoids
>> breaking any current experimental applications (and avoids them having any
>> incentive to UA-sniff).  Also, I think it works better in the dictionary.
>>    channel = peerconnection.createDataChannel(label, dictionary_object);
>> /* If either maxRetransmitTime or maxRetransmitNum are set, it's
>>     unreliable, else it's a reliable channel.  If both are set it's an
>>     error.  outOfOrderAllowed can be used with any type of channel.  The
>>     equivalent of UDP is { outOfOrderAllowed: true, maxRetransmitNum: 0 }.
>>     The TCP equivalent is {}.
>>     preset is set to true if the channel is being externally negotiated, and
>>     no wireline OpenRequest message should be sent.  If preset is true,
>> stream
>>     can be optionally used to set a specific SCTP stream to use.  If it's
>>     not set but preset is true, then the application should read the 'stream'
>>     attribute from the returned DataChannel after onopen and convey it to the
>>     other end to pass in via the DataChannelInit dictionary.
>>   */
> A lot of your text can be replaced by defaults on the dictionary.
> I prefer 'ordered' over 'outOfOrderAllowed', even if it means an
> inversion of the values.

Probably is easier to understand, and defaults help.

>    'rtxCount' or 'retransmitCount' rather than
> 'maxRetransmitNum'  (max is implied).

I don't know that removing 'max' helps here or hurts.  Also, 
sorta-acronyms like rtx are obvious to networking people; not so much to 
JS app developers.  I see only minimal advantage here to brevity.  Count 
might be an improvement on Num.

> 'preset' doesn't sound right, maybe you could have 'inlineOpen'
> (default: true) to convey what is really happening here.

externallyNegotiated (default: false)?  Not great, but "inlineOpen" will 
be pretty meaningless to most developers who probably could care less if 
there's an in-band open message for a channel (whether externally 
negotiated or not) - or even know there's an in-band message.  Then 
again, 99% of developers don't need to care about this anyways.

>> dictionary DataChannelInit {
>>    boolean ordered = true;
>>    unsigned short retransmitPeriod = 65535; // !
>>    unsigned short retransmitCount = 65535;
>>    DOMString protocol;    // default: undefined
>>    boolean inlineOpen = true;
>>    unsigned short stream;    // default: browser selected
>> };
> unsigned short is an unusual type for time intervals, even if you
> don't foresee a need for more than 65 seconds.  Oh, and that assumes
> that you are using milliseconds, right?

Unsigned short has been the type in the protocol fields since the first 
draft (like a year).  Perhaps a silly optimization, though I think if 
you want partial reliability with >64K resends, or >64 seconds of retry 
that you *really* want reliable transmission (perhaps unordered, but 
reliable).   If we want to change it, now's the time, since we're 
breaking binary compatibility in FF with my landing today anyways.

Randell Jesup

Received on Monday, 1 April 2013 20:00:53 UTC