Re: [rtcweb] DataChannels API and external negotiation

On 4/1/2013 4:24 PM, Martin Thomson wrote:
> On 1 April 2013 12:58, Randell Jesup <> wrote:
>>> '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").

I suggest one of "prearranged", or "externallyNegotiated" (both default: 
false).  I'd lean towards "prearranged", though it's not 100% correct.

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

We're not going to allow 3.5 retries though  :-)  or 1e25.  So: given 
choices of 16 bit unsigned, 32-bit unsigned or (seriously?) 64-bit 
unsigned, what do people want?  As I mentioned, I see little need for 
 >16bit unsigned (while not being reliable).  Yes, we'll be getting  a 
JS number, but we can a) inform the developer of the limits, and b) 
throw an error of some sort, *if* we think that's useful (quite possibly 

Randell Jesup

Received on Tuesday, 2 April 2013 05:40:12 UTC