Re: Capabilities vs SupportedConstraints

On 11/5/14, 6:22 PM, Martin Thomson wrote:
> On 4 November 2014 15:40, Rob Manson <robman@mob-labs.com> wrote:
>> Supported Constraints are the sub-set of Constraints that both the device
>> AND the UA are able to understand and attempt to apply (this is not just the
>> constraint-parsing table but also what the device drivers support).
> I don't see how this can be implemented without restructuring the API
> in a way that makes gUM less usable.

I agree with Martin. This would also be an information leak, and is not 
what I meant.

What I meant was that *if* we ever were to symmetrically add a top-level 
mediaDevices.getCapabilities() call that returned the aggregate of all 
available device information on the system - just like you would expect 
it to - then we should sprinkle in empty {} members for the remaining 
capabilities that the system has none of, for two reasons:

 1. Before permission is granted, ALL entries would be empty {} to avoid
    information leakage (without sprinkling there would be leakage).

 2. if (navigator.mediaDevices.getCapabilities().aspectRatio) would
    naturally tell you if the *browser* recognizes aspectRatio,
    regardless of permission, because {} returns true.

Such a function would totally replace the need for today's 
getSupportedConstraints(). That's the crux of my observation. Does 
anyone see us going that way ever? If so we wouldn't need two functions. 
That's the only reason I bring it up now.

> How about having "recognized constraints" instead, which is the set of
> constraints that the UA knows about and will either a) reject if it
> can't apply them for any reason, or b) apply them.

Yes, except "recognized capabilities" or "browser-supported 
capabilities" is more understandable to regular people I think.

"Vanilla" and "pistachio" are flavors of ice-cream first, 
ice-cream-order-form checkboxes second.

.: Jan-Ivar :.