W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Re: [rtcweb] DataChannels API and external negotiation

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 1 Apr 2013 13:24:47 -0700
Message-ID: <CABkgnnWe-+80WxD8==CxDhAu5+MEa-Tqi7Pr1x8sgkUkE9Z09Q@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
On 1 April 2013 12:58, Randell Jesup <randell-ietf@jesup.org> 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.
Received on Monday, 1 April 2013 20:25:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:42 UTC