Re: New API surface - inbound outbound streams/tracks

On 2012-11-12 14:08, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
> You are proposing to introduce an extremely complicated inheritance
> structure instead of adding 3 or 4 methods on RTCPeerConnection. How is
> that better? And even more important how is this to be explained to our
> users?

Can you describe more in detail what you think makes up the extremely 
complicated inheritance structure? The object structure is based on [1]; 
have I introduced the complexity with the additions I propose or is it 
inherited from that proposal?

The 3 or 4 methods on covers the DTMF case pretty well. But then we have 
stats, bitrate, priority and other settings people want to control on 
streams sent and received via a PeerConnection. I think it's beneficial 
to control these network streams similar to how local devices are 
controlled in [1] (*DeviceTrack objects).

>     pc.addStream(stream);
>     var outboundStream = pc.localStreams.getStreamById(
>     <>);
>     var outboundAudio = outboundStream.audioTracks[0]; // pending syntax
>     if (outboundAudio.canSendDTMF)
>          outboundAudio.insertTones("__123", ...);
> Having the same MediaStream magically change type feels just weird.

It's the corresponding stream that you retrieve from the 
PeerConnection's localStreams list that has an other type. The original 
stream reference is the same.

> To be compared to
>     pc.addStream(stream);
>     if (pc.canSendDTMF(...))
>        pc.sendDTMF(...);
> I agree that the second example won't win any prices for "Best designed
> API of the year" but it is infinitely simpler and to the point.

I think we'll need to add a bunch more methods on PeerConnection of the 
type pc.doSomething(targetTrack, ...) before we've exposed all the 
functionality people want. Do we need corresponding methods to read back 
such settings? I don't think it makes up a nice JavaScript API in the end.



Received on Monday, 12 November 2012 15:07:08 UTC