- From: Eero Häkkinen via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Mar 2023 08:55:08 +0000
- To: public-webrtc-logs@w3.org
> Steps 4 an 5 refer to settings dictionaries as if they were IDL dictionaries, having members. But settings dictionaries are not IDL dictionaries and their internal structure understood to be an implementation detail elsewhere in the spec. > > The spec explicitly says `We use the term settings dictionary for the set of values that might be applied as settings to the object.`, which does not necessarily translate to they working like IDL dictionaries with explicit members that might or might not be present. Settings dictionaries are not IDL dictionaries but the name _settings dictionary_ still implies that they are dictionaries. A dictionary is commonly defined to be data structure which has keys and values associated to those keys and its main immutable operations are to test the existence of a key and to retrieve the value associated to an existing key. > Another problem is that step 4 says `If constraintValue is a boolean, but the constrainable property is not`, which sounds impossible in IDL. It depends on the definition of the _constrainable property_ which I think is not properly defined in the spec. > I understand that this is intended to support pan/tilt/zoom constraints which accept boolean and numeric values. These constraints are of type (boolean or ConstraintDouble), so the constraint value is compatible with the property. [The Terminology section](https://w3c.github.io/mediacapture-main/#terminology) defines [Constraints](https://w3c.github.io/mediacapture-main/#dfn-constraint) and states that "[f]or each constrainable property, a constraint exists whose name corresponds with the relevant source setting name and capability name". So clearly a _constrainable property_ and a _constraint_ are two different things. Therefore, if a constraint is of type `(boolean or ConstraintDouble)`, it does not mean that the corresponding constrainable property is of that type. On the other hand, the [Constrainable Properties](https://w3c.github.io/mediacapture-main/#constrainable-properties) subsection under the [MediaStream API](https://w3c.github.io/mediacapture-main/#stream-api) section seems to kind of imply that _constrainable property_ and a _constraint_ mean the same. Could the step 4 be clarified to be `If constraintValue is a boolean, but the setting of the property is not`? The term _the setting of this property_ is used elsewhere in the spec. > One way to make this clearer is to treat this particular constraint type separately, just like purely numeric constraints are treated separately from purely boolean/enum/string constraints. Yes, that is one option for the step 4. But please note that the step 5 is in no way limited to constraints of type `(boolean or ConstraintDouble)`. It affects also for instance the 'focusMode' constraint of type `ConstrainDOMString`, the 'focusDistance' constraint of type `ConstrainDouble` and the 'backgroundBlur' constraint of type `ConstraintBoolean`. The step 5 defines that the fitness distance for an ideal constraint is 1.0 if the underlying device does not support the property or if the settings dictionary does not [expose](https://w3c.github.io/mediacapture-main/#dfn-must-not-be-exposed) the property. Of course that could be integrated to the steps 7 and 8 were the step 5 to be removed. -- GitHub Notification of comment by eehakkin Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/933#issuecomment-1451512946 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 March 2023 08:55:10 UTC