Re: Return value of getSupportedConstraints (Re: [Bug 26654] WebIDL types needed in Constrainable application)

On 10/10/2014 04:17 PM, Jan-Ivar Bruaroey wrote:
> On 10/10/14, 4:36 AM, Harald Alvestrand wrote:
>> I think Jan-Ivar's request #36 is uncontroversial, but I'd like some
>> list discussion on #37.
>>
>> The important change is that we use MediaTrackConstraintSet as the
>> return value for getCapabilities, getSettings and
>> getSupportedConstraints.
>>
>> What we previously thought, and what the change means:
>>
>> - getCapabilities returns a constraint set that indicates "the
>> maximum supportable values". I think using MediaTrackConstraintSet is
>> uncontroversial here.
>>
>> - getSettings returns something with the same keys as a constraint
>> set, and values of the same type as the type of the constraint set.
>> Returning bare values in a MediaTrackConstraintSet is a bit odd
>> (since the semantic of a bare value is "ideal" when it's passed in
>> the other direction), but seems not too odd to me.
>
> Correction: A) Capabilities are never passed in the other direction.
> B) The semantic of a bare value in MediaTrackConstraintSet when it is
> part of a constraint varies. When it is used in the advanced array
> then the semantic is "exact" (same as here), whereas when it it is
> used outside of the advanced array then it is "ideal". These semantics
> are imposed by the dictionary MediaTrackConstraints, not
> MediaTrackConstraintSet itself.

Not a correction, but more arguments for not considering it too odd for
use...

>
> Also - regardless of what we return - semantically, Settings is a
> proper subset of Capabilities, which #37 clarifies in prose (this was
> previously left for the reader to deduce). The argument for reuse of
> the superset here is that JS will only be reading these things and
> won't ever be able to tell the difference, thereby reducing the
> footprint of the documentation. #37 adds prose to guarantee only bare
> values will ever be returned. This is sufficient both to implement and
> to understand what's returned.
>
>> - getSupportedContraints returned a dictionary where the keys are the
>> same as for the constraint set, and where the values are all "true"
>> for supported constraints (and missing for non-supported constraints,
>> naturally). Using MediaTrackConstraintSet means that the values have
>> to be of the corresponding types, and be "truthy" - which means that
>> we need special treatment for constraints that have the possibility
>> of being zero, empty string or other "falsy" things. This seems a bit
>> iffy.
>
> Correction: The values returned need only be truthy. No special
> treatment is needed for any constraint regardless of what it normally
> produces, since the purpose is not to return data in this API, but to
> return something truthy to reflect support, and to return with
> constraints absent to reflect absence of support.

Again, I don't think this is a correction.

Returning a truthy value requires changing the returned value according
to what the type of the constraint is. That's the odd part.

>
> .: Jan-Ivar :.
>


-- 
Surveillance is pervasive. Go Dark.

Received on Friday, 10 October 2014 17:06:17 UTC