W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2014

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

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Fri, 10 Oct 2014 10:17:40 -0400
Message-ID: <5437EA84.4060805@mozilla.com>
To: Harald Alvestrand <harald@alvestrand.no>, public-media-capture@w3.org
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.

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.

.: Jan-Ivar :.
Received on Friday, 10 October 2014 14:18:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:30 UTC