- From: Peter Thatcher <pthatcher@google.com>
- Date: Wed, 3 Apr 2013 09:05:46 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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". 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". 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; }; On Mon, Apr 1, 2013 at 1:24 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 1 April 2013 12:58, Randell Jesup <randell-ietf@jesup.org> wrote: >> I don't know that removing 'max' helps here or hurts. Also, sorta-acronyms >> like rtx are obvious to networking people; not so much to JS app developers. >> I see only minimal advantage here to brevity. Count might be an improvement >> on Num. > > Yeah, 'rtx' is probably too aggressively short. > >>> 'preset' doesn't sound right, maybe you could have 'inlineOpen' >>> (default: true) to convey what is really happening here. >> >> >> externallyNegotiated (default: false)? Not great, but "inlineOpen" will be >> pretty meaningless to most developers who probably could care less if >> there's an in-band open message for a channel (whether externally negotiated >> or not) - or even know there's an in-band message. Then again, 99% of >> developers don't need to care about this anyways. > > Yes, I didn't get a warm fuzzy from my suggested name either, but you > are right about the impact being relatively low. > > Other ideas: "announceSettings" (default: true), "prearranged" > (default: false), "thisIsNotATest" (default: "yesItIs"). > >> Unsigned short has been the type in the protocol fields since the first >> draft (like a year). Perhaps a silly optimization, though I think if you >> want partial reliability with >64K resends, or >64 seconds of retry that you >> *really* want reliable transmission (perhaps unordered, but reliable). If >> we want to change it, now's the time, since we're breaking binary >> compatibility in FF with my landing today anyways. > > Well, you'll be accepting a JS number, so it doesn't really matter > what the spec says. > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
Received on Wednesday, 3 April 2013 18:07:45 UTC