Re: Possible Constraint Syntax Compromise

So everyone is okay with browsers firing the success callback on unknown 
constraints?

I ask because point #3 (below) doesn't make this obvious that this is 
the case.

Gili

On 21/05/2014 8:57 AM, Dan Burnett wrote:
> I'm in favor of this proposal.  It's a very simple, 
> easily-understandable change to what's in the current editor's draft 
> that cleans up the WebIDL-inspired "required" hack.
>
> -- dan
>
> On May 20, 2014, at 5:57 PM, Peter Thatcher wrote:
>
>> Here at the interim meeting in DC, I've noticed a lot of disagreement 
>> about the constraint syntax, which has led to hours of heated 
>> discussion and a halting of progress.  After talking to a bunch of 
>> people here about it, it seems like the biggest issue is over how we 
>> specify "required".  If we can figure out how to clean that up, I 
>> think we can progress and come to agreement on other things like 
>> "ideal" and "advanced".  I shared an idea here locally for how we 
>> could clean up "required" that would service as a baseline of 
>> consensus, from which we could then progress with more discussion 
>> about advanced topics, and have some consensus to fall back to.
>>
>> So here's my proposal for how to cleanup the "required" part, which 
>> seems to make everyone happy (out of the 5 or so people I have spoken 
>> to about it).
>> ​  ​
>> Feel free to send comments here.  The chairs have already scheduled 
>> time tomorrow morning to discuss this topic.
>> ​  ​
>> FYI, Cullen took an action item from the meeting yesterday to propose 
>> something like this, and he has said he's happy with this proposal, 
>> so consider it part of that action item.
>>
>>
>> ===
>> ​ ​
>> Changes from whats in the editor’s draft today
>>  ​ ​
>> ===
>>
>> 1.  Remove "required: ["height", "width"]" and replace it with {..., 
>> "required": true} inside of each given constraint.
>>
>> 2. Add "static MediaStreamTrack.getSupportedContstraints()" which 
>> returns an object with details about what contraints are supported. 
>>  To start, it will be {"height": true, "width": true, ...}. In the 
>> future, we may have something more than true/false.  But this should 
>> give us future flexibility.  And it makes it easy for the JS to check 
>> if a given constraint is supported (it's easier to check the 
>> existense of a key in a map than an array).
>>
>> 3.  If the JS wants a non-supported constraint to be required, then 
>> it will first need to check if it's supported and then do the right 
>> error handling if it isn't.  It can't expect a browser to blow up if 
>> it requires an unsupported constraint.
>>
>> 4.
>> ​ ​
>> "ideal"/"advanced"
>> ​​
>>  is orthogonal to this change and is thus not shown in order to make 
>> the changes more obvious.
>>
>>
>> ===
>> ​ ​
>> Examples
>>  ​ ​
>> ===
>>
>> Before
>> ​ ​
>> changes
>> ​
>> :
>>
>> getUserMedia({
>>  // If "depth" not supported, you get an error
>>  “required”: ["width", "depth", “facingMode”],
>>  “width”: {"min": 320, "max":1920},
>>  “height”: {"min":240, "max":1080},
>>  “depth”: ...,
>>  “facingMode”: “environment”
>> }, ...);
>>
>>
>> After
>>  ​ ​
>> changes
>> ​:​
>>
>>
>> if (!MediaStreamTrack.getSupportedConstraints()["depth"]) {
>>  // Act just like if getUserMedia returned an error.
>> }
>>
>> getUserMedia({
>>  “width”: {"min": 320, "max":1920, "required": true},
>>  “height”: {"max":240, "max":1080},
>>  “depth”: {..., "required": true},
>>  “facingMode”: {“value”: “environment”, "required": true}
>> }, ...);
>>
>>
>> ===
>>  ​ ​
>> Pros
>> ​ ​
>> ===
>>
>> -
>> ​ ​
>> The "required: ["foo", "bar"]"  hack is gone (prettier!).
>>
>>
>> ===
>> ​ ​
>> Cons
>> ​ ​
>> ===
>>
>> -
>>  ​ ​
>> The JS ha
>> ​s​
>>  to check for what is supported before trying to use it.
>