W3C home > Mailing lists > Public > public-media-capture@w3.org > August 2012

Re: Revised Constraints modification API proposal

From: Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 23 Aug 2012 12:16:38 +0200
Message-ID: <50360306.7060203@alvestrand.no>
To: public-media-capture@w3.org
On 08/22/2012 08:44 PM, Travis Leithead wrote:
>> 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.
And if the application is one like my "Android "Search Light" 
application, where the whole, only, and complete point of the 
application is to turn on the flash?

I wouldn't like to constrain applications to only those that use devices 
in the ways we expect.

Received on Thursday, 23 August 2012 10:17:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:11 UTC