W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > May 2016

[mediacapture-main] Specify relation between return from getConstraints and constraints argument

From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
Date: Wed, 25 May 2016 11:18:08 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issues.opened-156724970-1464175087-sysbot+gh@w3.org>
alvestrand has just created a new issue for 
https://github.com/w3c/mediacapture-main:

== Specify relation between return from getConstraints and constraints
 argument ==
The current constrainable-pattern getConstraints() text says:

"The getConstraints method returns the Constraints that were the 
argument to the most recent successful call of applyConstraints(), 
maintaining the order in which they were specified. Note that some of 
the optional ConstraintSets returned may not be currently satisfied. 
To check which ConstraintSets are currently in effect, the application
 should use getSettings."


I think we should specify that what's returned is the semantic 
equivalent of what was passed in, as seen from the browser. When 
implementing this, I found that it was onerous to preserve the exact 
form passed in. In particular:

- Unrecognized constraints are stripped away by the parser. We 
shouldn't have to return them.
- Since { width: { ideal: 570 }} and { width: 570 } are semantically 
identical, we should either be free to return either form, or we 
should require that the simpler form be returned.
- Same for { deviceId: [ "foo" ] } and { deviceId: "foo" }

Suggested modification:

"The getConstraints method returns a set of constraints that is 
semantically equivalent to the argument to the most  recent successful
 call of applyConstraints(), maintaining the order of "advanced" 
elements that was specified. Note that...."


Please view or discuss this issue at 
https://github.com/w3c/mediacapture-main/issues/360 using your GitHub 
account
Received on Wednesday, 25 May 2016 11:18:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:29 UTC