Re: New version of constrainable section of getusermedia

On Feb 3, 2014, at 2:41 PM, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:

> On 1/31/14 8:05 PM, 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.
>> 
> 
> I thank the editors and Jim for their hard work and for putting this topic in focus like this. The text has certainly benefited from the work-over.
> 
> We definitely need this for gUM, however I think it remains to be seen whether this pattern has applicability beyond gUM. In the last few months, we have extricated it from webrtc and we seem to be leaning the same way with MediaRecorder.
> 
> The reason I bring this up, is because the things I wish to pick on have to do with the abstraction attempt in the first place. These are things I've mentioned before, like:
> 
> [NoInterfaceObject
> ]
> interface 
> Constrainable
>  {
> 
>     Capabilities getCapabilities ();
>     Constraints  getConstraints ();
>     Settings     getSettings ();
>     void         applyConstraints (Constraints constraints, VoidFunction successCallback, ConstraintErrorCallback 
> err
>  orCallbac
> k
> );
>                 attribute EventHandler onoverconstrained;
> 
> };
> 
> 
> The fact that the Constrainable webidl interface is defined as operating on the discrete webidl dictionaries named "Capabilities", "Constraints" and "Settings", which A) except for Constraints, aren't defined! and B) more importantly, implies that all disparate uses of Constrainable (e.g. today's getUserMedia and, say, a future getCompanionCube) must operate on the same dictionaries "Capabilities", "Settings" and "Constraints", with implications like name-collisions for members, and a larger confusion about whether constraints, capabilities and settings in one domain must be expected to work in all others.
> 
> I can't believe this is intended, so my best-effort interpretation is that what we mean is for this to be a template, a pattern to repeat but not take literally. E.g:
> 
> [NoInterfaceObject
> ]
> interface Gum
> Constrainable
>  {
> 
>     GumCapabilities getCapabilities ();
>     GumConstraints  getConstraints ();
>     GumSettings     getSettings ();
>     void         applyConstraints (GumConstraints constraints, VoidFunction successCallback, ConstraintErrorCallback 
> 
>  errorCall
> back
> );
>                 attribute EventHandler onoverconstrained;
> 
> };
> 
> 
> [
> NoInterfaceObject
> ]
> interface 
> CCubeConstrainable
>  {
> 
>     CCubeCapabilities getCapabilities ();
>     CCubeConstraints  getConstraints ();
>     CCubeSettings     getSettings ();
>     void         applyConstraints (CCubeConstraints constraints, VoidFunction successCallback, ConstraintErrorCallback 
> errorCa
> llback
> );
>                 attribute EventHandler onoverconstrained;
> 
> };
> 

I’m not following you on how the names collide. Lets say there is a name called width which is used by CCube and Gum but mean totally differ things. How do they collide? I don’t think this was mean to be a template - the setting is just a list of names that can be used in keys - Constraints are a bunch of keys along with allowed range - and settings are keys along with their current value.

Received on Monday, 3 February 2014 22:47:24 UTC