- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Thu, 04 Apr 2013 08:52:01 +0200
- 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