- 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