Calling attention: Constraints and MinMaxValues

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.
- 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?

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.

        Harald

Received on Monday, 6 May 2013 11:31:16 UTC