Re: Capabilities vs SupportedConstraints

On 11/4/14, 1:28 PM, Harald Alvestrand wrote:
> SupportedConstraints was added to get around the question of "how do I
> know that my requests won't just be ignored because of the Dictionary
> rules?".

It actually has some use: It tells you upfront what this browser can and 
can't say about the user's system.

> The natural (to me, anyway) way of generating supported constraints is
> to have the UA dump the content of its constraint-parsing lookup table,
> without any regard to whether there are any such devices or not. So I'd
> expect getSupportedConstraints() to return a lot of strings like
> "reallyFutzyExperimentalConstraint" and "propertyOfDeviceNobodyHas".
>
> getCapabilities, on the other hand, should return the constraints that
> are actually useful for a specific context - they should reasonably be
> generated by asking each device driver what constraints it supports and
> what the values are - for "propertyOfDeviceNobodyHas", I don't expect it
> to turn up in any getCapabilities return value - it's just a guarantee
> that if you send down "propertyOfDeviceNobodyHas: { exact: 55 }", you'll
> get a failure to apply.

I think you're focusing on the least useful aspect. If fail-always is 
what you want from "propertyOfDeviceNobodyHas", then just omit it from 
getSupportedConstraints().

The important guarantee (to me) is that { propertyOfDeviceNobodyHas: { 
exact: 55 } } failing means the user in fact /*does not have*/ a 
55-PoDNH-sporting device. [1]

> Because of the dictionary rules, if you send down
> "propertyOfDeviceNobodyHad: { exact: 55 }" (note the misspelling), the
> constraint will be ignored.

Nothing here catches typos, so how is this relevant?

> So to my mind, they're fundamentally, deeply different, and SHOULD NOT
> be merged.

I disagree with you and agree with Rob that these are fundamentally the 
same "things". Their */use /*is fundamentally different.

The usage difference can be bridged by returning: { 
propertyOfDeviceNobodyHas: { } } from getSupportedCapabilities (to use 
the proposed name) even when permissions are granted, to mean: "yes I 
know what it means, and no the user doesn't have any of those". 
Dictionaries can already be empty, so no additional logic would be 
needed for this.

.: 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