Re: Constraints 2014

I am now of this opinion as well. But if we're not going to be able to get
there, I prefer "Constraints 2014" as a slimmed-down version of constraints
that can be implemented more readily.

However, I am opposed to the C2014 pattern of dumping both audio and video
qualifiers into a single bag of options. sourceId already points out the
danger in doing so; I think we should avoid future trouble and scope
qualifiers to a media type, e.g.

 var constraints = {
      video: {
        require: ["width", "height"],
        width: { min: 640, max: 1280 },
        height: { min: 480, max: 768 },
        aspectRatio: 16/9,
        frameRate: 60,
    }
  };


On Mon, Mar 24, 2014 at 8:41 AM, cowwoc <cowwoc@bbs.darktech.org> wrote:

> +1
>
> For what it's worth, I agree with Martin that developers should be able to
> enumerate device capabilities instead of jumping through all these silly
> hoops. This will result in a much cleaner API.
>
> Gili
>
>
> On 23/03/2014 8:27 PM, Martin Thomson wrote:
>
>> (No argument with the rest of it.  However...)
>>
>> On 23 March 2014 14:52, Jim Barnett <1jhbarnett@gmail.com> wrote:
>>
>>> The lengthiest dispute/discussion was over whether the application
>>> should be
>>> notified which mandatory constraints failed.  Some people felt this made
>>> fingerprinting too easy, others felt that information was important for
>>> intelligent applications.   The latter group has prevailed.
>>>
>> I have no idea about what is the prevailing attitude here.  However, I
>> will observe that if we permit the use of immediate errors that
>> include information on what mandatory constraints could not be met,
>> then the difference between that and a complete enumeration of device
>> capabilities is effectively nil [1].
>>
>> If we do provide an error indication like this, then I will - again -
>> repeat that we should instead be enumerating device capabilities
>> completely.  That enumeration should expose capabilities as affected
>> by other users of the system.  (For the fingerprinting averse, this
>> means that you get to learn about some combination of the system, and
>> the other users of the system, probably both over time.)
>>
>> [1] If you are clever, you can almost protect a single capability by
>> ordering enforcement, forcing the app to risk asking the user to probe
>> its state, though that's also trivial to avoid.  For instance, if you
>> a protecting resolution by enforcing its constrain last, the app can
>> ask for something implausibly large.  This allows it to safely probe
>> all other capabilities.  Then, if the app is willing to take the
>> chance that the browser asks the user, it can reduce resolution one
>> pixel at a time until the user prompt appears, thus revealing
>> resolution capabilities precisely.  Protecting an unordered capability
>> with many states could reduce the chance that the app successfully
>> probes its state without triggering a user prompt.
>>
>>
>
>