Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

[Harald Alvestrand <[e-mail]>]

On 06/19/2013 05:15 PM, Peter Thatcher wrote:
>
>
>
> On Mon, Jun 17, 2013 at 6:00 PM, Silvia Pfeiffer 
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     Hi Peter, all,
>
>     I'm looking at all this from the view of a JS developer and I am
>     really excited that there is movement in this space. Having hit my
>     head hard against the limitations of the current WebRTC API and being
>     forced to learn SDP to achieve some of the less common use cases, I'm
>     feeling the pain. I am therefore happy to see that there is a proposal
>     for a higher-level API with similarities to the Microsoft's CU-WebRTC
>     proposal and I hope that together with Microsoft's input this can
>     become a really useful API.
>
>
> I hope so as well.  Unfortunately, Microsoft's input seems to be "our 
> way or the highway" and the input of others seems to be "SDP ought to 
> be enough for anybody".  My thinking is that we can make incremental 
> improvements toward a cleaner API without being so extreme at either 
> end.  And I hope I can find others that think similarly.
>
>
>     What I would like to see, though, is a bit different from what you've
>     proposed. In particular, the MediaFlowDescription object is the one
>     object that I believe is supposed to enable JS developers to  do "SDP
>     hacking" without having to understand SDP. Unfortunately, the way in
>     which it is currently written, this API doesn't help a JS developer
>     much. There are properties in that object like "ssrc" that mean
>     nothing unless you understand SDP.
>
>
> Actually, it helps some JS developer a lot.  It happens to be very 
> good for the JS I am writing :).
>

And it might be really obvioius and come across as really condescending, 
but there's absolutely no way anyone can write sensible code to control 
the parameters of transmission or encoding without understanding how 
that controlling affects the transmission or encoding.

Thus, as long as one uses RTP, one needs to understand concepts like 
payload types, SSRCs, RTP sessions, RTCP feedback and so on - OR accept 
that one programs to a higher level abstraction where these attributes 
are not visible, and accept that one does not have control over them.

In some cases, interfaces can be made with "options" - so that if one 
doesn't care, one gets a sensible default, and if one does care, one can 
get detailed control - but sometimes, one has to pick the level of an 
interface.

I'd like to think that we recognize that these tradeoffs have to be made.