- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Mar 2023 15:22:22 +0000
- To: public-webrtc-logs@w3.org
> Since properties are a pattern and not a specific IDL definition (beyond the name of the property), sometimes the spec uses the setting type when describing the property and sometimes it uses the constraint type. I agree that the spec should be more consistent here Agreed, and thanks for spotting this! I've filed https://github.com/w3c/mediacapture-main/issues/945 to address this. Regarding the remainder of the conversation (which has gotten long), to scope it down, it seems centered on confusion regarding https://github.com/w3c/mediacapture-main/pull/766, is that fair? > But the concept we are interested in is whether a dictionary setting satisfies a constraint or not, see [Step 2](https://w3c.github.io/mediacapture-main/#dfn-fitness-distance). Thus, having a numeric setting and a boolean value for the constraint doesn't mean that the setting cannot be checked to satisfy the constraint. IIUC, if the setting supports any numeric value it means it satisfies a true value for the constraint. Here's [step 2](https://w3c.github.io/mediacapture-main/#dfn-required) today: _"If the constraint is required (constraintValue either contains one or more members named 'min', 'max', or 'exact', or is itself a bare value and bare values are to be treated as 'exact'), and the [settings dictionary](https://w3c.github.io/mediacapture-main/#dfn-settings-dictionary)'s constraintName member's value does not satisfy the constraint or doesn't [exist](https://infra.spec.whatwg.org/#map-exists), the fitness distance is positive infinity."_ What "satisfies" (before #766) was considered self-evident by language like _"[The maximum legal value of this property.](https://w3c.github.io/mediacapture-main/#dom-doublerange-max)"_ (opening another issue https://github.com/w3c/mediacapture-main/issues/946, sigh). #766 [added](https://github.com/w3c/mediacapture-main/pull/766/files#diff-1217ca1c44ff30a33dd50c49d03b5cadc9633c789df8ff9370ed4a42859e1211R4243) the _"or doesn't [exist](https://infra.spec.whatwg.org/#map-exists)"_ part, which perhaps requires clarification. Our thinking here was that during getUserMedia especially, the fitness algorithm needs to take into account devices that have pan/tilt/zoom and those that don't. The former devices would have pan/tilt/zoom members in their settings dictionaries, while the latter devices would not. The _"or doesn't [exist](https://infra.spec.whatwg.org/#map-exists)"_ part should be clear that `pan: true` results in infinity for the latter devices. But I agree it is perhaps unclear that the settings dictionaries of the former devices "satisfy" `pan: true`. I'm happy to take language to clarify that sentence. I'd like to keep changes here limited however, as I don't think a major refactor of the algorithm is needed here, or desirable if we can avoid it. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/933#issuecomment-1485328901 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 27 March 2023 15:22:24 UTC