Re: Overconstrained

On 2013-03-25 18:35, Martin Thomson wrote:
> I have made this case before, but I believe that it is worth repeating.
>
> Constraints present a very complicated API.  I do not believe that
> there are real use cases that cannot be supported with mandatory
> constraints and a number of attempts to change those mandatory
> constraints.
>
> I would like to propose that we remove optional constraints.
>
> Sure, it's relatively easy to contrive examples, but I don't believe
> that there is anything that a real-world application would unable to
> do using a mandatory-only constraints API.
>
> To add to this, a lot of the new features we are dicussing
> (capabilities, better device information) only makes optional
> constraints less relevant.
>
> If we retain these, I'd like to see better justification for their existence.

I think this makes sense when constraints are set with the 
constraints()/applyConstraints() API. Optional constraints doesn't make 
much sense there what I can see. It would even be possible to implement 
our current algorithm for optional constraints if we have a good 
mechanism for handling the "over constrained" case and rolling back.

I not as convinced when it comes to constraints at getUserMedia() time. 
The mandatory constraints could be used to filter out all but two 
cameras. We can't mimic the effect a second run of optional constraints 
would have on those cameras unless we return both cameras to the app and 
run the JS-version of the optional constraints as described above.

My preference would be that we only have one type of constraints that 
are treated as optional at getUserMedia() time and mandatory with the 
constraints()/applyConstraints() API. I'm not sure that's workable though.

I think this still needs some work and the best thing would be to have 
some real use cases and apply the different methods to those.

/Adam

Received on Tuesday, 26 March 2013 10:46:14 UTC