RE: Revised Constraints modification API proposal

> From: Travis Leithead [mailto:travis.leithead@microsoft.com]
> 
> > From: Dan Burnett [mailto:dburnett@voxeo.com] On Aug 21, 2012, at 4:56
> > PM, Travis Leithead wrote:
> > > As a reminder, the goal of this proposal is to facilitate "informed
> > > constraints" (i.e., allow constraints to be applied after existing
> > > client capabilities are known) in order to avoid potential pitfalls
> > > of blindly over-constrained use of getUserMedia across a range of
> > > different
> > devices.
> >
> > I always wanted to have capabilities along with constraints, and I'm
> > pleased to see (finally) a realistic capabilities proposal.  Given
> > that we will not always have capabilities available for privacy
> > reasons, I'd like to understand better these "potential pitfalls of
> > blindly over-constrained use".  I have heard that mentioned but have
> > not yet seen enough evidence to convince me that this is a real problem.
> Could you point me to some examples?
> 
> [TODO]

Ha ha! Sent too soon.

Well, there have been a few discussions on this in the past. The big
hangup I have with it, is the ability to make pretty much any optional constraint
a mandatory constraint.

This, in theory, leads to potentially goofy mandatory constraints like "must have
a flash" which causes every device without a flash to be flat-out rejected. My 
general belief is that while the developer is trying to be helpful, it's really up
to the user to determine what is acceptable. If the video appears too dark, then 
try to turn on the flash, but don't have the UA enforce that constraint before giving
the user a chance to try it out.

Obviously, I'm OK with video/audio as mandatory constraints. This is because those
are really not constraints, but device selection criteria. Perhaps there's some room 
here for compromise, but as the current design stands, I'm not comfortable with it.

Received on Wednesday, 22 August 2012 18:44:59 UTC