Re: Proposal: Constraints as dictionaries

On 2013-11-22 16:48, Jan-Ivar Bruaroey wrote:
> On 11/22/13 4:23 AM, Adam Bergkvist wrote:
>> Even with applyConstraints() you might still want express something as
>> an acceptable range and then check the setting what you're actually
>> getting. Also, even though the applyConstraints() call succeeded,
>> there might be changing circumstances that prevents the UA from living
>> up to the developers wishes. The constraint concept has a way to deal
>> with that.
>
> You're the one who wanted to leave out optional here. :-)

I'm not sure what you mean.

>
> Thanks for clarifying. I think I understand now. Min/max ranges, when
> used with track.applyConstraints(), leave wiggle-room for a browser or
> device to pick its preferred value or even vary the value over time if
> they need to. Sounds useful. Can we please spell that out in the spec?

It can always be made clearer but I think we have it:

 From Terminology section:
"Constraints are an optional feature for restricting the range of 
allowed variability on a source. Without provided constraints, 
implementations are free to select a source's settings from the full 
ranges of its supported capabilities, and to adjust those settings at 
any time for any reason."

 From 10. Constrainable Interface section:
"The application can select the (range of) values it wants for a 
Capability by means of a Constraint and the applyConstraints() method. A 
Constraint consists of the name of the property, plus the desired value 
(or a range of desired values.)"

I have thought about a picture to describe this in the form of a range.

Capability    Constraint    Setting
[----------------[============X======]---------------------]

> This is subtly different from gUM() which is picking from mutually
> exclusive sets of capabilities, and I now appreciate the symmetry of why
> we shouldn't overload min/max with "give me highest/lowest in range"
> there (because the overload is taken), which wasn't obvious to me before.

The selection part for gUM() is special, but I as understand it, the 
constraint will remain after the selection and from that point on they 
should work as if they had been set with applyConstraints().

> To answer your earlier question, you definitely want optional in there
> then, since optional expresses preference, just like ranges do.

The question is if optional constraints does the job in the current 
form. Since a constraint may be disregarded, the preference expressed 
with that constraint may be thrown away. The method of guarding up with 
several levels of optional constraints is not that intuitive.

/Adam

Received on Monday, 25 November 2013 10:18:01 UTC