Re: IDL/API feedback

On 2013-04-08 09:21, Anne van Kesteren wrote:
> On Mon, Apr 8, 2013 at 6:08 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com> wrote:
>> On 2013-04-07 12:57, Anne van Kesteren wrote:
>>> 2) The addtrack and removetrack events are not defined. In particular,
>>> when they are dispatched.
>>
>> Both of the above issues were fixed recently, but haven't made it into a
>> released version yet. They are available on github [1].
>
> The second issue does not appear to be fixed (the methods are not
> dispatching these events). It's also unclear why you'd need a special
> interface for this event given that you can get to the tracks on the
> object already.

Which methods are you referring to? It's deliberate that addTrack() and 
removeTrack() don't fire this event. The event is intended to notify the 
script that, for example, the remote and has added a track to a stream 
that you're receiving. Therefore, nothing in the Media Capture spec 
fires this event a.t.m..

Regarding the event interface, you're right that the tracks are 
available on the stream (in the "addtrack" case), but we've found it 
motivated to supply the track since it's rather inconvenient to, for 
example, determine which track is the new one because of the current 
data structure.

>>> 3) The constructor for MediaStream should probably a sequence of
>>> MediaStreamTrack, not an IDL array.
>>
>> It's not a big deal, but wouldn't a sequence introduce an extra (and
>> unnecessary) copy of the array when it's passed by value? Are there any
>> general guidelines for array-like input arguments? I've seen that at least
>> the WebSocket constructor uses a DOMString[] for its protocols argument.
>
> You need a copy. If you'd actually pass by value the developer could
> make further changes later that would have to be reflected by the
> object, which is not what you want at all.

I suspect you mean pass by reference above. It not really a problem in 
our case since the MediaStream constructor only reads the content of the 
list; it doesn't adopt it. Thus, the copy is in vain.

> With regards to WebSocket, that seems like a bug in WebSocket.

Ok. We would be happy to follow a common pattern on this even if the 
motivation simply is - that's how it's done everywhere else.

/Adam

Received on Monday, 8 April 2013 08:02:39 UTC