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

Received on Wednesday, 16 October 2013 05:29:45 UTC