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

Re: [rtcweb] DataChannels API and external negotiation

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 4 Apr 2013 09:19:16 +0200
Message-ID: <515D2974.7030802@ericsson.com>
To: public-webrtc@w3.org
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.
Received on Thursday, 4 April 2013 07:19:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC