Re: Constraints as a separate interface

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

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

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

* in "Property Registry", the "set of legal values" can be of type
"boolean, min-max range, or enumerated list of values"; I think we want
to allow for other type of simple values, such a integers and doubles
(e.g. {width:640})

* ProvertyValueRange and PropertyValueList are defined but not referred
from any WebIDL:
- I don't understand the value of having an interface for
PropertyValueRange (and a constructor) where a simple dictionary would
work; 
- the typedef for PropertyValueList when that name isn't used anywhere
seems of pretty dubious value;
- I think there is a confusion between formalizing the values that can
be used in the registry (that formalization doesn't need to be done in
WebIDL), and defining the types that values of constrainable properties
can take; for the latter, PropertyValueRange would make sense (but
again, as a dictionary); my understanding is that the type for values of
constrainable properties would be something like (boolean or long or
double or DOMString or PropertyValueRange) (but I may have missed some
other useful value types — maybe "any" is the best we could do)

* 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

* 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

Received on Friday, 11 October 2013 07:39:24 UTC