Re: The UNKNOWN mandatory constraint behavior is a footgun

On 15/11/2013 11:51 AM, Jan-Ivar Bruaroey wrote:
> The prime feature of mandatory is not that it fails (callback btw. not 
> exception). If it were it could be a boolean. The prime feature is 
> expressiveness. (In fact I argue in
>
> If we just take out mandatory now, then I worry the optional structure 
> alone isn't expressive enough to handle some of the width/height 
> min/max cases I've seen. Don't we risk the browser (putting the wrong 
> camera at the top of the choice-list and) returning the wrong camera? 
> I think it is essential that getUserMedia() return the best camera the 
> first time.
>
> Gili, if you are referring to my "dictionaries of decreasing 
> preference" proposal 
> http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0052.html 
> , then I agree with you, as that structure supports (AND)OR implicitly.
>
> If you're arguing we should not throw ConstraintNotSatisfiedError then 
> that's 
> http://lists.w3.org/Archives/Public/public-media-capture/2013Nov/0078.html 
> and I agree. The app should inspect what's returned instead. No need 
> to optimize for failure.
>
> .: Jan-Ivar :.
>

What you wrote above is good, but I would go a step further. Instead of 
risking the browser returning the wrong camera, we move the decision 
making into the application:

 1. The API exposes a list of available devices/capabilities that are
    theoretically available. For example, resolutions would be the union
    of all resolutions available across all devices.
 2. The developer passes a "dictionaries of decreasing preferences" to
    the API based on the above list.
 3. The browser returns a list of "candidates" (specific devices and
    capabilities from #2 that they support) . This list may contain
    additional information than request in #2. For example, #2 might
    have requested 720p but this step mentions that the camera also
    supports 3D. This allows developers to pick the best out of a list
    of acceptable candidates.
 4. The developer picks one candidate and passes it back to the API.
 5. The API prompts the user for access for that candidate (and nothing
    else).
 6. If accepted, an "opened" device is returned to the developer.

Devices + capabilities would transition through these phases:

Available -> Candidates -> Open -> ... -> Closed

Available (step 1) is the union of all capabilities
Candidates (step 2) binds capabilities to specific devices
Open (step 3) grants the application access to the device
Closed (step 4) occurs when the application releases the device

Gili