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

Re: Capabilities vs SupportedConstraints

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Tue, 04 Nov 2014 21:00:00 -0500
Message-ID: <545984A0.5000603@mozilla.com>
To: Rob Manson <robman@mob-labs.com>, public-media-capture@w3.org
Supported means supported. The browser cannot throw any key it's heard 
of into getSupportedConstraints without implementing it, because A) the 
spec says it can't [1], and B) it would be dumb since the net effect 
would be nothing:

For a required constraint:
- If it's not in getSupportedConstraints, then we say clients should 
treat it as failure.
- If it's in getSupportedConstraints but unimplemented,  then it would 
always fail.

That's the same outcome. We don't need two ways to reach the same effect.

The value and purpose of getSupportedConstraints then is to know what's 
actually implemented. Makes sense, is useful and seems clear to me. [2]

.: Jan-Ivar :.

[1] "Any constraint names not supported by the User Agent MUST not be 
present in the returned dictionary." - 

[2] If "supported" just meant "any constraint-name we've loosely heard 
about and decided to stuff into our parsing-lookup table just in case 
and because we could" then that makes statement [1] circular and 
nonsensical. Thus the negated MUST-phrasing above exists to enforce 
implementation, not to keep out rainbow tables.
Received on Wednesday, 5 November 2014 02:00:29 UTC

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