Re: New version of constrainable section of getusermedia

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

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.
>
> 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:03:36 UTC