RE: Constraints at request time (Re: Revised Constraints modification API proposal)

> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> 
> I think that there are 3 different things involved here.
> 1) Device properties.  These represent immutable aspects of the device.
> Likely examples are whether it produces audio or video, and possibly the
> direction it faces (for built-in devices).
> 2) Device capabilities.  These represent things that the device can do, but
> doesn't necessarily have to do.  Some cameras may be able to rotate, so for
> them direction is a capability, not a property.  (But the capability may apply
> only within a range, for example, when a camera can rotate up to 90 degrees
> but no further.)
> 3) Device settings.  These are the specific values selected for the capabilities,
> via the commands  that Harald mentions.
> 
> In principal, there are three different, but related, APIs needed here:
> One to request devices with specific properties and capabilities,  one to
> describe the capabilities of the devices that are returned, and one to apply
> settings to devices. If we have a constraint language that can describe the
> device's capabilities (i.e. range of possible values) _and_ the device's current
> setting, it can support all 3 APIs.  (A property as a special case of capability: it's
> one that has a range of 0 or 1, depending on your point of view).
> 
> One question is  whether we would want the command/settings API to
> select a range, rather than a specific value (e.g., I want the camera to point
> within 5 degrees of direction x)

Here's what I'd like to see:
getUserMedia:
* supports required device properties
* supports optional device capabilities (this helps browsers build a smarter UX for initial camera selection but does not exclude devices based on capability)

getSettings():
* returns optional device capabilities (those with range values other than binary)

applySettings(x):
* supports required device capabilities with a failure notification mechanism

Settings that are binary should just be made into read/write properties for convenience

I think that at this point we need to get concrete about which capabilities we want to expose in V1 of our specification (Rich suggested a few already) and how our proposed mechanisms work with them. 

I'll plan to revise my proposal again based on the existing feedback.

Received on Thursday, 23 August 2012 19:24:32 UTC