Re: Possible Constraint Syntax Compromise

I think represents a good compromise between the proposal I talked to people about and the current syntax. I like this change to what is currently in the draft. 

On May 20, 2014, at 5:57 PM, Peter Thatcher <pthatcher@google.com> 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.

Received on Wednesday, 21 May 2014 12:41:52 UTC