Re: IDL/API feedback

On Mon, Apr 8, 2013 at 9:02 AM, Adam Bergkvist
<adam.bergkvist@ericsson.com> wrote:
> 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..

It might be worth clarifying that.


> 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.

Okay.


>> 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.

I just read the relevant sections of IDL again. If you convert an ES
value to an IDL array it'll go through the convert to sequence steps
anyway. Unless it's the rare case of it being a platform array object,
which it almost certainly is not.


>> 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.

I think we should really clean up IDL here. I believe it has ended up
with [] only to be used for readonly arrays, which is super
counter-intuitive.


--
http://annevankesteren.nl/

Received on Monday, 8 April 2013 08:15:28 UTC