Re: [rtcweb] DataChannels API and external negotiation

["[e-mail]" <[e-mail]>]

I agree with Peter (all the parameter in a dictionary), also with the
one about to put the label inside it. Also this way, it would be the
label optional too and be able to identify the DataChannel this way
using the other parameters, as for example the protocol.

2013/4/3 Randell Jesup <[e-mail]>:
> Adding W3 list back ("Reply List" replies to one list in TB), since this
> really is a W3 item anyways.
>
> On 4/3/2013 12:19 PM, Randell Jesup wrote:
>>
>> On 4/3/2013 12:05 PM, Peter Thatcher wrote:
>>>
>>> I think moving protocol into the dictionary is a good idea.   In fact,
>>> I'd like to see label move there as well, but that's probably asking
>>> too much.
>>>
>>> And now for a little of my own bikeshedding:
>>>
>>> I don't understand way we have "stream" and "preset", since you can
>>> only set "stream" if "preset" is true.  Why not just make the rule "if
>>> stream is set, no in-band message is sent", and get rid of "preset"
>>> altogether?  I really don't like the word "stream" sneaking in, since
>>> it's so overloaded (MediaStream, RTP Stream, etc).  I'd prefer "sid"
>>> or just "id".
>>
>>
>> The reason was that I wanted a way to have the system select a stream to
>> use (that you can then communicate externally to the other side); this
>> avoids any chance of a collision with existing streams. If this is seen as
>> not useful, then we can collapse it to a single entry.   (I also toyed with
>> using stream 65535 as a flag to tell the system to allocate one; that seemed
>> too hacky.)
>>
>> Since this option was almost solely for those who understand the
>> underlying SCTP-ness of this, I used "stream", but I'm fine with "streamId"
>> or "id" (or "index" might be better than "id", which sounds like a label of
>> some sort).  I dislike "sid" for similar reasons to disliking "rtx".
>>
>>
>>> I like the idea that reliable+ordered is the default, and both
>>> reliability and ordered can be set independently.  I also prefer
>>> "ordered" over "outOfOrderAllowed", and along with that I like the
>>> idea of a "reliable" flag that, if false, is the equivalent of either
>>> maxRetransmitNum:0 or maxRetransmitTime:0.  Finally, I think
>>> "maxRetransmitTime" should make its units clear, perhaps calling it
>>> "maxRetransmitMillis", and "maxRetransmitNum" could be shortened to
>>> simply "maxRetransmits".
>>
>>
>> Those seem reasonable (I'd use Millisec/MilliSec or perhaps MS instead of
>> Millis -- how are millisecond time values in other HTML5 specs described?).
>> On "reliable:false" - is this just a shorthand for "ordered:false,
>> maxRetransmits:0"?  If so, I'm probably ok with it - it's redundant, but
>> makes it easy to use/read for a common case.
>>
>>
>>>
>>> So the dictionary for my bikeshed would be:
>>>
>>> dictionary DataChannelInit {
>>>    DOMString protocol;
>>>    unsigned short id;
>>>    boolean ordered;
>>>    boolean reliable;
>>>    unsigned short maxRetransmits;
>>>    unsigned short maxRetransmitMillis;
>>> };
>>
>>
>
>
> --
> Randell Jesup
> [e-mail]
>
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux