Re: Constraints as a separate interface

On 10/11/13 3:39 AM, Dominique Hazael-Massieux wrote:
> Hi Jim
>
> Le dimanche 06 octobre 2013 à 22:09 +0000, Jim Barnett a écrit :
>> Here’s an attempt to separate constraints out into a separate
>> interface.
> Thanks for your work on this! Here are some comments on the proposed
> constrainable interface — I think some of these likely intersects with
> comments I raised in Bugzilla for the current getUserMedia spec, but
> it's also likely that these comments provide more input as to how to
> address them.
>
> I'm fine if most of these comments don't make it for the first
> integration in Media Capture given that these problems already exist in
> the current draft of the spec anyway.
>
> * I think Constrainable should be defined as a [NoInterfaceObject]
> interface — I don't think it's an interface that particularly need to be
> exposed to the global scope, and I assume it will be re-used by other
> interfaces via "Foo implements Constrainable" statements

Hi Dominique, your comment here didn't gel with my understanding of what 
Jim said, so (maybe I'm wrong and) I wanted to check.

When Jim says "The point is to allow other specs, such as MediaRecorder, 
to refer to it and ensure that they are all using constraints 
consistently.  This does _/not/_ change the semantics of constraints," - 
I interpreted this to mean that this "partial interface" is a rhetorical 
device, if you will, that is to have absolutely zero impact on how we 
implement this webidl versus today. - Jim, can you clarify?

If we instead intend for this to be a separately query-able interface, 
then I'd like to understand exactly how that would work. A draft of how 
the corresponding webrtc section would be affected might clarify this.

Also, the term "partial interface" seems used in a novel way in the 
prose here. I thought the term meant to continue a same-named interface, 
as if it were defined as a whole, much like namespaces in c++. - But the 
name is different here, which I find confusing.

For instance, if this *is* meant to be a separate interface, then we 
could give the applyConstraints() method a simpler apply() name, or use 
similar shorthands.

> * the "constraints()" method should probably be renamed
> "getConstraints()" to make its semantics clearer; likewise for
> settings() and capabilities()

I agree.

> *  alternatively, they might be exposed under the same name as
> currently, but as attributes; any reason why these are exposed as
> methods rather than readonly attributes?

Because webidl attributes must be identical in comparison with identical 
objects of the same API (or itself), and dictionaries are returned as 
copies, is my understanding.

> [...]
>
> * the interface "Constraint" and "ConstraintSet" don't have a WebIDL
> definition; given that the name of their properties are only defined by
> reference, I don't think we can use dictionaries to define them as the
> prose suggests; I think a [MapClass] interface definition is probably
> what we would want [1]
> [MapClass(DOMString,(boolean or long or double or DOMString or
> PropertyValueRange)] interface ConstraintSet {};
> Then Constraint[] would be replaced by ConstraintSet[] (I don't see a
> reason to define a separate "Constraint" interface — the current prose
> for Constraint and ConstraintSet are exactly the same).
>
> Note that defining a MapClass requires to define the list of map entries
> (in our case, the list of constraints), and an order for it.
>
> 1. http://dev.w3.org/2006/webapi/WebIDL/#MapClass

I've encountered difficulties implementing constraints using webidl 
dictionaries (I'll make a separate post on this), but MapClass? - I've 
used that pattern to implement a browser-object that JS gets array-like 
access to, but I'm not able to see how this helps here. An example might 
help.

.: Jan-Ivar :.

> * Settings and Capabilities would then be replaced in WebIDL by
> ConstraintSet (since again, we can't use dictionaries with undefined
> members)
>
> * examples would be useful
>
> HTH,
>
> Dom