Re: Capabilities vs SupportedConstraints

On 11/2/14, 2:54 AM, Rob Manson wrote:
> Yeah...the language to me seems like it would be "If I change my 
> Constraint upon the volume Capability what Setting will I end up with?"

Exactly.

>> As for what SupportedConstraints() should return or be called, I 
>> argue in the same PR for returning what effectively amounts to a 
>> MediaCapabilities with "opaque" values. With your observation, it 
>> might be interesting to explore whether it could return something 
>> more detailed once permission is granted (somewhat like 
>> enumerateDevices does).
>
> +1 but then I think it could be better named 
> SupportedCapabilities()...but I do get that it's about finding out 
> what Constraints you can apply to turn potential Capabilities into 
> explicit Settings.

+1 on renaming. It's actually less of a weird conceit than "supported 
constraints". Clients *have* constraints; browsers "support" 
capabilities for clients to express constraints upon them.

Additionally, *if* we wanted to go further and explore having it return 
aggregate capabilities in cases where (persistent) permissions are 
already granted - like enumerateDevices does - then we could call it 
getCapabilities (on mediaDevices, like on MediaStreamTrack)!

E.g. when permission is granted, you might get:

   { width: {min: 320, max: 1280 }, ... }

meaning: no camera on this system can do higher than 1280. Without 
permission, you'd get:

   { width: { }, ... }

Both would happen to serve its existing purpose (iff width is in the 
returned dictionary then the browser knows about width).

I would normally resist this as feature-creep, but admit I find the 
symmetry appealing and perhaps even easier to understand overall.

> roBman

.: Jan-Ivar :.

Received on Monday, 3 November 2014 15:59:30 UTC