Re: New version of constrainable section of getusermedia

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.  However, if it cannot, it does not raise an overconstrained event.

- 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

Received on Monday, 3 February 2014 15:50:04 UTC