Re: Calling attention: Constraints and MinMaxValues

A few comments from me below.

-- dan

On May 6, 2013, at 7:30 AM, Harald Alvestrand wrote:

> One thing I don't think we have discussed that much explicitly is the concept of exact values and min/max values.
> 
> In the original and current implementation of constraints, we defined a constraint as either a minimum or a maximum, or possibly a member of an enumerated set; in all cases, the value was a simple value.
> 
> In the current spec (in the registration chapter, currently chapter 12), we have the following options:
> 
> - Enums (sourceType, facingMode)
> - Unconstrainted string (sourceId)
> - Exact values (unsigned long for width, float for frameRate)
> - Min/Max values, defined as:
> 
> dictionary MinMaxConstraint {
>    any max;
>    any min;
> };
> 
> (I think this last needs to have a few question marks added, so that min or max can be omitted; otherwise, we can't express a pure "min" or "max" value any more. Detail.)
> 
> Now this is a rich set of options, with some interesting implications:
> 
> - Exact values need to be applied with some fuzz - or need to be applied exactly, which may lead to unexpected failures. The spec needs to pick one.

Exact values are intended to be a shortcut for simultaneously applying min and max, so this is not a new type but rather syntactic sugar.  It was also already a part of what we agreed to at the last interim.

> - Min/max values, specified together, need to be evaluated together. This means that if the constraint fails to apply, we might be unable to report whether the range was above or below the possible values. Is this a problem?

This is an interesting point.  If exact values are merely syntactic sugar, then an optional Width:5 is equivalent to optional minWidth:5, maxWidth:5 which means that you could get one but not the other.  Then again, they are optional in this example.  If you have a mandatory Width:5 then it doesn't matter which failed -- you can't get the value of 5 that you want and you will get an error (or overconstrained).

> 
> Things to think about for tomorrow:
> 
> - Are we OK with these options?
> - Are these the only options we want to consider, or should we let registrations add more?
> - Are there rules we need to write down about how these are handled?
> 
> I like these. But it's a change, and change means that we need to figure out the implications of it.

The only real change is the addition of the unconstrained string.  That is a big change, but one which is hard to avoid in the case of the sourceId.  Do you have an alternative that would work for sourceId?

> 
>       Harald
> 
>

Received on Tuesday, 7 May 2013 14:15:36 UTC