Re: Possible Constraint Syntax Compromise

I'm in favor of this change! Stefan

On 2014-05-20 23:59, 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.

Received on Wednesday, 21 May 2014 12:17:12 UTC