- From: Jan-Ivar Bruaroey <jib@mozilla.com>
- Date: Tue, 04 Nov 2014 21:00:00 -0500
- 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." - http://w3c.github.io/mediacapture-main/getusermedia.html#methods-4 [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