Re: New version of constrainable section of getusermedia

Hi

I've heard Dan describe optional constraints as a way to express 
preference: for example order of importance. Even if not all optional 
constraints can be satisfied, the structure still represents the 
preference of the developer. If we remove stuff from the structure 
because some constraints can't be met right now, then the entire 
optional structure might express a different preference at a later 
point. For example, we threw away a constraint at t0 which would have 
meant something at a later point t1 (where more resources were available).

/Adam

On 2014-02-03 17:07, Jim Barnett wrote:
> I can see the logic in asking the UA to always try to satisfy all
> constraints, but I am afraid of the burder this might place on UAs. In
> the current language the UA finishes applyConstraints with a set of
> values that satisfy the current constraints. All it has to do is check
> when things change to see if any of them cannot be satisfied any more.
> It might be more work to always be checking to see if currently
> unsatisfied optional constraints can now be satisfied, particularly
> since the ordering of the optional constraints means that it has to look
> at the whole list of constraints - not just the ones that are currently
> unsatisfied.
>
> If implementers think that it would be easy to do this, then it
> certainly gives the app author more control.  But it like to know how
> hard it is first.
>
> - Jim
>
>
> On 2/3/2014 10:58 AM, Stefan Håkansson LK wrote:
>> On 2014-02-03 16:49, Jim Barnett wrote:
>>> Yes, you're right.  "set of constraints" is too vague.  It should be
>>> changed.   The language in onoverconstrained is more precise, and the
>>> overconstrained event is raised only if the mandatory constraints are
>>> violated.  However, when the UA chooses new values, shouldn't we say
>>> that it must choose values that satisfy the optional constraints if it
>>> can.
>> I think so; but that brings me back to my earlier comment: if the
>> mandatory ConstraintSet can be satisfied when doing applyConstraints,
>> should not the entire Constraint dictionary (i.e. all optional
>> ConstraintSets) be passed on to the object? If the UA changes values
>> later, we would like it to take all, not only the ones that could be
>> satisfied at applyConstraints-time, optional constraints into account,
>> wouldn't we? (I may be thinking along the wrong lines...)

Received on Tuesday, 4 February 2014 07:05:46 UTC