RE: Constraints as a separate interface

Jan-Ivar,
I phrased things poorly since I don’t know much about webIDL.  The goal is to define the interface in one place (the Media Capture spec) and have MediaStreamTracks and MediaRecorder and possibly other classes refer to it  (as a former LISP/Clos programmer, I would say “inherit it”) without having to redefine it.   So I want to be able to add _some_ succinct expression to the definition of MediaRecorder that makes it clear that you can query it’s Capabilities and Settings, and affect the Settings by applying Constraints.  Furthermore, any spec that wants to use this interface should need to list only the relevant Capabilities and their types/ranges.    If someone will tell me what the correct webIDL for this is, I’ll be glad to use it.

When I said that it doesn’t change the semantics of MediaTrack, I mean that it doesn’t change the behavior that developers will see (except for minor syntactic tweaks.)  There’s been a lot of discussion on the list about exactly how Streams and Tracks should be created and manipulated, how getUserMedia should work, etc.  All I’m really saying is that I’m not trying to smuggle some particular point of view on those issues into the spec.


-          Jim

From: Jan-Ivar Bruaroey [mailto:jib@mozilla.com]
Sent: Tuesday, October 15, 2013 10:39 AM
To: public-media-capture@w3.org
Subject: 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