Re: New version of constrainable section of getusermedia

Yes, but I'm not sure what our "must" is if we require the UA to keep 
all the constraints.  The current requirements are straightforward: you 
evaluate all constraints once, keep the ones that are satisfied, and 
then report if later changes make it impossible to satisfy the mandatory 
constraints.  If we require the UA to keep all the constraints, how hard 
must it try to satisfy the currently unsatisfied ones?  How often should 
it check?  Do we just have a "should" here, with no concrete 
requirements on the UA?

- Jim
P.S.  In any case, I would think that getConstraints() would return only 
the constraints that were satisfied at the moment, not all of them.  
That's a detail that would have to be reflected in the algorithm.

On 2/4/2014 2:05 AM, Adam Bergkvist wrote:
> 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...)
>

-- 
Jim Barnett
Genesys

Received on Tuesday, 4 February 2014 14:32:04 UTC