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

Re: [rtcweb] DataChannels API and external negotiation

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 04 Apr 2013 08:52:01 +0200
Message-ID: <515D2311.3070700@alvestrand.no>
To: public-webrtc@w3.org
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.


>
>
> So, I update my proposed dictionary to be the following:
>
> dictionary DataChannelInit {
>    DOMString label;  //  default: chosen by browser.
>    DOMString protocol;  // default: undefined
>    unsigned short id;  // default: chosen by browser.
>    boolean ordered = true;
>    boolean reliable = true;  //  false is just a synonym for maxRetransmits: 0.
>    unsigned short maxRetransmits;  // default:  "forever"
>    unsigned short maxRetransmitMilliseconds;  // default: "forever"
>    boolean sendOpenMessage = true;
> };
>
> On Wed, Apr 3, 2013 at 9:21 AM, Randell Jesup <randell-ietf@jesup.org> wrote:
>> Adding W3 list back ("Reply List" replies to one list in TB), since this
>> really is a W3 item anyways.
>>
>>
>> On 4/3/2013 12:19 PM, Randell Jesup wrote:
>>> On 4/3/2013 12:05 PM, Peter Thatcher wrote:
>>>> I think moving protocol into the dictionary is a good idea.   In fact,
>>>> I'd like to see label move there as well, but that's probably asking
>>>> too much.
>>>>
>>>> And now for a little of my own bikeshedding:
>>>>
>>>> I don't understand way we have "stream" and "preset", since you can
>>>> only set "stream" if "preset" is true.  Why not just make the rule "if
>>>> stream is set, no in-band message is sent", and get rid of "preset"
>>>> altogether?  I really don't like the word "stream" sneaking in, since
>>>> it's so overloaded (MediaStream, RTP Stream, etc).  I'd prefer "sid"
>>>> or just "id".
>>>
>>> The reason was that I wanted a way to have the system select a stream to
>>> use (that you can then communicate externally to the other side); this
>>> avoids any chance of a collision with existing streams. If this is seen as
>>> not useful, then we can collapse it to a single entry.   (I also toyed with
>>> using stream 65535 as a flag to tell the system to allocate one; that seemed
>>> too hacky.)
>>>
>>> Since this option was almost solely for those who understand the
>>> underlying SCTP-ness of this, I used "stream", but I'm fine with "streamId"
>>> or "id" (or "index" might be better than "id", which sounds like a label of
>>> some sort).  I dislike "sid" for similar reasons to disliking "rtx".
>>>
>>>> I like the idea that reliable+ordered is the default, and both
>>>> reliability and ordered can be set independently.  I also prefer
>>>> "ordered" over "outOfOrderAllowed", and along with that I like the
>>>> idea of a "reliable" flag that, if false, is the equivalent of either
>>>> maxRetransmitNum:0 or maxRetransmitTime:0.  Finally, I think
>>>> "maxRetransmitTime" should make its units clear, perhaps calling it
>>>> "maxRetransmitMillis", and "maxRetransmitNum" could be shortened to
>>>> simply "maxRetransmits".
>>>
>>> Those seem reasonable (I'd use Millisec/MilliSec or perhaps MS instead of
>>> Millis -- how are millisecond time values in other HTML5 specs described?).
>>> On "reliable:false" - is this just a shorthand for "ordered:false,
>>> maxRetransmits:0"?  If so, I'm probably ok with it - it's redundant, but
>>> makes it easy to use/read for a common case.
>>>
>>>> So the dictionary for my bikeshed would be:
>>>>
>>>> dictionary DataChannelInit {
>>>>     DOMString protocol;
>>>>     unsigned short id;
>>>>     boolean ordered;
>>>>     boolean reliable;
>>>>     unsigned short maxRetransmits;
>>>>     unsigned short maxRetransmitMillis;
>>>> };
>>>
>>
>> --
>> Randell Jesup
>> randell-ietf@jesup.org
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
Received on Thursday, 4 April 2013 06:52:32 UTC

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