- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Fri, 02 May 2014 16:47:36 -0400
- To: Jan-Ivar Bruaroey <jib@mozilla.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, public-webrtc@w3.org
- Message-ID: <53640468.1030106@bbs.darktech.org>
On 02/05/2014 4:31 PM, Jan-Ivar Bruaroey wrote:
> On 5/2/14 6:40 AM, Adam Bergkvist wrote:
>> pc.updateIce({ "iceTransports": newValue });
>>
>> The above updates single option,
>
> That is incorrect. It also sets requestIdentity to "ifconfigured":
>
> dictionary RTCConfiguration {
> sequence<RTCIceServer> iceServers;
> RTCIceTransports iceTransports = "all";
> RTCIdentityOption requestIdentity = "ifconfigured";
> };
>
> Absence is not feasible or detectable with default values, just like
> with default values on c++ function-arguments. Like in c++, the
> function cannot distinguish between "ifconfigured" actually being
> passed in and nothing being passed in.
>
> Said another way: webidl binding-code literally fills in the default
> values before handing it to the implementation (or in the case of a
> return value, back to content).
>
> Therefore, updateIce as described here
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#methods
>> 2. If the iceTransports member was omitted and the ICE Agent's ICE
>> transports setting is unset, set the ICE Agent's ICE transports
>> setting to the iceTransports dictionary member default value.
>
> is not implementable using webidl-bindings, because there's no way to
> test whether the iceTransports member was omitted, because it has a
> default value in webidl.
>
> Said another way: Our spec cannot dictate implementation logic around
> default values, because that behavior is well-defined.
>
> I recommend treating webidl behavior as invariant in all descriptions
> of implementation and return values. e.g. remove all mention of
> default values in prose.
>
> .: Jan-Ivar :.
>
Or, use a different dictionary for the initial configuration and
updating an existing configuration. The former would have defaults. The
latter would not. Or just use the Builder pattern :)
Gili
Received on Friday, 2 May 2014 20:48:40 UTC