Re: [rtcweb] DataChannels API and external negotiation

[Peter Thatcher <[e-mail]>]

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

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

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;
};

On Mon, Apr 1, 2013 at 1:24 PM, Martin Thomson <[e-mail]> wrote:
> On 1 April 2013 12:58, Randell Jesup <[e-mail]> wrote:
>> 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.
>
> Yeah, 'rtx' is probably too aggressively short.
>
>>> '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.
>
> Yes, I didn't get a warm fuzzy from my suggested name either, but you
> are right about the impact being relatively low.
>
> Other ideas: "announceSettings" (default: true), "prearranged"
> (default: false), "thisIsNotATest" (default: "yesItIs").
>
>> 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.
>
> Well, you'll be accepting a JS number, so it doesn't really matter
> what the spec says.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb