Re: New version of constrainable section of getusermedia

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

>
>> However, if it cannot, it does not raise an overconstrained event.
> Right.
>
>> - Jim
>>
>> , Stefan Håkansson LK wrote:
>>> On 2014-02-03 16:05, Jim Barnett wrote:
>>>> Stefan,
>>>>      My responses in-line
>>>> On 2/3/2014 4:31 AM, Stefan Håkansson LK wrote:
>>>>> Many thanks (to everyone that contributed) for getting this put together.
>>>>>
>>>>> I think it reflects well the functionality that people have been asking
>>>>> for constraints (and that we've been discussing over and over again, and
>>>>> come back to there is a need for), such as:
>>>>> * enable selection of input devices
>>>>> * enable "must" and "preferred" operation modes
>>>>> * inform the app if a "must" can't be met - both at application time and
>>>>> at run time
>>>>> * inform the app if it tries to influence something the UA does not
>>>>> understand
>>>>>
>>>>> Reading through, I have a couple of questions:
>>>>>
>>>>> Is there a need for queuing? applyConstraints() has callbacks; could
>>>>> there be a situation when applyConstraints() immediately followed by
>>>>> getConstraints() would get the old ones (not the ones just applied)?
>>>>    >> Yes, this could definitely happen, since applyConstraints is queued
>>>> but getConstraints isn't.  The same holds for getSettings.
>>>> applyConstraints is queued because it could take a while, while
>>>> getConstraints/Settings/Capabilities are just returning a copy of a data
>>>> structure.  Perhaps they should all be queued.
>>>>> Section 11.1.2, step 6: I'm not sure about the value of adding only the
>>>>> optional ConstraintSets that can be satisfied to newConstraints. Can't
>>>>> the optional constraints be seen as a wish list that the UA (together
>>>>> with the underlying system) will make its best to meet (in order), but
>>>>> no guarantees? And, even if a ConstraintSet can't be met right at
>>>>> application time, it could be possible shortly afterwards (and vice
>>>>> versa: something can happen at runtime meaning that an optional
>>>>> ConstraintSet that could be met at application time can no longer be
>>>>> met). If the application want to know the status at runtime it has to
>>>>> check the current Settings.
>>>>    >> The mandatory constraint set is also added to newConstraints.
>>>> getConstraints returns the set of ConstraintSets that were successfully
>>>> applied by the last successful call to applyConstraints.  It's the set
>>>> of ConstraintSets that the UA is currently trying to satisfy.  We don't
>>>> require the UA to keep trying to satisfy the optional constraints that
>>>> failed in the last call to applyConstraints.  Wouldn't it be a burden on
>>>> the UA to require that?  It's easy enough to change the spec to require
>>>> the UA to keep trying to satisfy the failed optional constraints, but
>>>> I'd like to hear what implementers think.
>>> That's a good point.
>>>
>>>>> Section 11.1.2, last step (7) in algo, there is a not ending "...
>>>>> satisfy the current set of constraints." 'set of constraints' is not
>>>>> well defined, should it be 'Constraints in effect' instead? Further, is
>>>>> it not so that the UA can modify any value at any time to any value,
>>>>> _but_ if the modification renders a value go outside the boundaries set
>>>>> up by the mandatory ConstraintSet it should fire the "overconstrained"
>>>>> Event?
>>>>    >> That language has been moved to the onoverconstrained section.  The
>>>> spec says "if changing circumstances at runtime result in the currently
>>>> valid mandatory ConstraintSet no longer being satisfied."  Isn't
>>>> 'currently valid mandatory ConstraintSet' precise, given the definition
>>>> of applyConstraints?   What should it say instead?
>>> 'currently valid mandatory ConstraintSet' is definitely precise. 'set of constraints' in step 7 of 11.1.2 is not IMO.
>>>> As for the UA being able to modify values at any time,  we do need
>>>> normative language in the spec describing how this works.  My
>>>> understanding has always been that the UA may only choose new values
>>>> that satisfy all the ConstraintSets in getConstraints.  If it cannot do
>>>> this, it must raised onoverconstrained.
>>> My understanding was that the UA may only choose new values that satisfy
>>> *the mandatory* ConstraintSets in getConstraints . In other words, there
>>> would be no event informing the app if an accepted optional
>>> ConstraintSet can no longer be satisfied.
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>>> On 2014-02-01 02:06, Cullen Jennings (fluffy) wrote:
>>>>>> There is a new version of the draft at
>>>>>>
>>>>>> http://dev.w3.org/2011/webrtc/editor/archives/20140130/getusermedia.html
>>>>>>
>>>>>> We deleted most of it text in it.
>>>>>>
>>>>>> Don’t Panic
>>>>>>
>>>>>> We deleted all the sections except section 11 which is the Constrainable interface. We just wanted to get the new Constrainable section out for everyone to read and discuss. This is the generic interface that deals with constraints. If people agree with this, we can go make all the changes to the rest of the document to line up with this interface and then publish the full draft.
>>>>>>
>>>>>> Thanks,  <The editors>
>>>>>>
>>>>>> ( And thanks to Jim who contributed a bunch of the text for this section )
>>>>>>
>>>>>> PS - Since this interface is equally important to webrtc and getUserMedia, I have taken the liberty to send it both lists.
>>>>>>
>>>>>>
>>>>>>     
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>

-- 
Jim Barnett
Genesys