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


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