Re: [rtcweb] DataChannels API and external negotiation

On 2013-04-04 09:19, Stefan Håkansson LK wrote:
> On 4/4/13 8:52 AM, Harald Alvestrand wrote:
>> On 04/04/2013 05:12 AM, Peter Thatcher wrote:
>>> Randell, thanks for explaining.  I think it's a valid use case to say
>>> "I don't want the in-band open message, but I do want you to choose
>>> the SID for me".  In that case, I'm OK with a separate flag meaning
>>> "send the in-band open message", and I'd prefer a name like
>>> "sendOpenMessage" or "sendControlMessages", which would default to
>>> true.
>>>
>>> On "sid", If you don't like "sid", I'm OK with "id", or even
>>> "streamid", but I prefer "id" over "streamid".  I don't like "index".
>>>
>>> On "millis" vs. "millsecs", the closest thing in HTML I could find was
>>> the Date object, which has "getMilliseconds".  That would lean us
>>> toward "maxRetransmitMillieseconds", which seems too long.  But I
>>> don't care too much about this name, and would be happy with any of
>>> "maxRetransmitMs" or "maxRetransmitMillis",
>>> "maxRetransmitMilliseconds", "maxRetransmitTime" or
>>> "maxRetransmitDuration".
>>>
>>> On "reliable: false", I'd say it's a synonym for "maxRetransmits: 0".
>>> You can have "{ordered: true; reliable: false"} or "{ordered: false;
>>> reliable: true}", which is the same as "{ordered:true,
>>> maxRetransmits:0}" or "{ordered:false}", respectively.
>>>
>>> Michael, you don't have to set "reliable: true", since that's the
>>> default.  This is only to allow "reliable: false" as a more readable
>>> and easy to understand way of saying "maxRetransmits: 0".  It's purely
>>> a convenience synonym.
>>>
>>> Finally, if it's possible for us to make such a breaking change, I do
>>> think it makes sense to optionally allow the browser to choose the
>>> label, just as it optionally chooses the sid.  As such, I'll include
>>> that idea in the dictionary I propose below so that createDataChannel
>>> would take only one argument, this dictionary (like so:
>>> createDataChannel({"label: XYZ", ...}).  If everyone else dislikes
>>> this idea, then so be, take out that field and keep the rest.  I feel
>>> more strongly about the rest of the names and options than I do about
>>> that one.  But if we can make the change, I think it makes the method
>>> cleaner and more flexible.
>>
>> I'd prefer the label to remain outside.
>>
>> I think the most common pattern will be
>>
>> createDataChannel("foo")
>>
>> which should (in my opinion) create a reliable, in-order data channel
>> with an init message, and behaviour that is otherwise extremely like a
>> WebSocket.
>
> I share Harald's view.

I'm with Harald and Stefan on the label-bit.

Otherwise I like the way the names have evolved in this thread as well 
as the separate "reliable" option and "protocol" in the dictionary.

However, the "sendOpenMessage" option might seem a bit strange to JS 
developers that don't know/care about the underlying protocol. Is this a 
message that need to be handled in the "message" handler? I'm leaning 
more towards something like "externallyNegotiated" (false) which Randell 
proposed. Or we could have "autoNegotiate(ed)" (true), "autoConnect(ed)" 
(true).

/Adam

Received on Thursday, 4 April 2013 10:44:55 UTC