Re: New editor's draft (v20130603)

On 2013-06-14 12:31, Randell Jesup wrote:
> On 6/13/2013 11:31 PM, Adam Bergkvist wrote:
>> On 2013-06-13 18:56, Randell Jesup wrote:
>>> On 6/5/2013 4:59 AM, Adam Bergkvist wrote:
>>>> On 2013-06-04 16:34, Randell Jesup wrote:
>>>>>
>>>>> One issue:   In RTCDataChannelInit:
>>>>>
>>>>>      boolean          negotiated
>>>>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannelInit-negotiated>
>>>>>
>>>>> =true;
>>>>>
>>>>> The default should be false - it should be set to true on any
>>>>> externally-negotiated channel.
>>>>
>
>>> I'm ok with the name and description, so long as the default changes to
>>> 'false', which is what I implemented and landed.  We should just comment
>>> in the IDL file that this should be set to true if the application is
>>> using external negotiation.   I believe Peter Thatcher was also assuming
>>> the default would be false.
>>>
>>
>> So I interpret what you're saying as that "negotiated" will be
>> released in firefox, but with the opposite meaning from spec is saying
>> currently (spec says "negotiated" != "externally negotiated"). I'm bit
>> confused since you say that you're ok with the name and description.
>
> Sorry if I wasn't clear.  Let me try again:
>
> Currently it says "negotiated=true;", and in the descriptive part it says:
>
> |    negotiated| of type boolean, defaulting to |true|
>
>     The default value of true tells the user agent to negotiate the
>     channel and instruct the other peer to dispatch a corresponding
>     ||RTCDataChannel|
>     <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
>     object. If set to false, the negotiation is omitted and it is up to
>     the script to create the corresponding ||RTCDataChannel|
>     <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
>     object at the other peer.
>
> ||Re-reading this carefully, I myself may have been confused when I
> quickly read it (the draft came out the same day I had to get changes
> in).  I probably could have implemented it as written, because *both*
> the meaning and the default were flipped from what I expected (and thus
> "createDataChannel("",{})" would have indeed still caused in-channel
> Open messages to occur).
>
> The current definition confused me on the first read, because when we
> send Open messages, there is no negotiation, they're declarative.  So
> "negotiated=true" as the definition was confusing, since it said we were
> negotiating when in fact we're not.  This is reflected in my rewording
> below to use the word "notify".
>
> So, again to be clear, this is what we'll be shipping in Fx 22, and I
> would suggest we change the definition to match this:
>
> |    negotiated| of type boolean, defaulting to |false|
>
>     The default value of false tells the user agent to create the
>     channel and notify the other peer to create the channel and fire an
>     event named datachannel to the peer's corresponding
>     ||RTCDataChannel|
>     <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
>     object. If set to true, then no channel creation notification will
>     be sent to the other peer, and it is up to the script to ensure
>     creation of the corresponding ||RTCDataChannel|
>     <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|
>     object at the other peer.
>
> ||This also changes the wording to use 'fire an event named datachannel'
> to match usage elsewhere in the draft for events.
>
> This definition means "createDataChannel("",{})" will send an Open and
> cause ondatachannel, and "createDataChannel("",{negotiated=true})" will
> not send an Open, and will assume that the application has either
> pre-defined a channel or is negotiating the channel itself (externally).

Thanks for clarifying this. As long as we're clear in documentation what 
negotiation is; a thing you do in JavaScript when you create two 
separate DataChannel objects and connect them, then I think we're good.

I'll update the spec accordingly.

/Adam

Received on Friday, 14 June 2013 11:35:31 UTC