Re: Constraints as a separate interface

On 10/16/13 8:34 AM, Jim Barnett wrote:
> I have turned getConstraints(), getSettings() into readonly attributes constraints and settings.  I think that’s the simplest thing to do since it makes it clear that there's no way to modify the value except by using applyConstraints.

As I already replied to Dominique (see bold below), dictionaries cannot 
be attributes. From http://dev.w3.org/2006/webapi/WebIDL/#idl-dictionaries :
> Dictionaries MUST NOT be used as the type of an attribute 
> <http://dev.w3.org/2006/webapi/WebIDL/#dfn-attribute>, constant 
> <http://dev.w3.org/2006/webapi/WebIDL/#dfn-constant> or exception 
> field <http://dev.w3.org/2006/webapi/WebIDL/#dfn-exception-field>. 

.: Jan-Ivar :.

>
> - Jim
>
> -----Original Message-----
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> Sent: Wednesday, October 16, 2013 1:29 AM
> To: Jan-Ivar Bruaroey
> Cc: public-media-capture@w3.org
> Subject: Re: Constraints as a separate interface
>
> On 2013-10-15 16:39, Jan-Ivar Bruaroey wrote:
>> 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.
> Constrainable isn't a partial interface so I agree that the text shouldn't say that. The interface is meant to be used as "MediaStreamTrack implements Constrainable". So MediaStreamTrack is compatible with the constraints concept via this extra set of methods that are defined in Constrainable. This is quite similar to how EventTarget used to work (before it was inherited).
>
> Regarding [NoInterfaceObject], I have no problem if it would be possible to do "myTrack instanceof Constrainable", but I don't think it's that necessary.
>
>>> * 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.
>> *
> Yes. applyConstraints() is the only way to change constraints from the script so we can't return an object that, when modified, changes the object's current constraints. I agree with the comments regarding the "get" prefix; we have that for other similar methods (e.g.
> MediaStream.getAudioTracks()).
>
> /Adam
>