Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

On Fri, Jul 19, 2013 at 10:49 AM, Adam Roach <adam@nostrum.com> wrote:

> On 7/19/13 12:18, Peter Thatcher wrote:
>
>> Please try to consider what you sound like to a web developer who is
>> trying to use WebRTC and finding SDP to be difficult API surface.
>>
>
> I think any time someone says they've used the SDP directly as a control
> surface in a JavaScript application, it indicates a hole in the current
> WebRTC specification that we need to fix.
>
> SDP is not supposed to be the WebRTC API surface.
>
> I think we all pretty much agree that SDP is not supposed to be the WebRTC
> API surface.
>
> I think we're pretty much all on the same page that we need to add stuff
> to the current API to handle these use cases.


If SDP isn't the control surface, than what is the API surface?  The only
way to tell the browser to setup an ICE connection is to give it SDP.  The
only way to tell it to send and receive RTP packets is to give it SDP.  The
browser might produce the SDP for you, and you might be told not to change
it, but at the end of the day, the commands that make the browser setup ICE
connections and send and receive RTP is the SDP.   Therefore, SDP is the
API control surface.  Until JS can setup an ICE connection and send and
receive RTP packets without giving the browser SDP, then SDP is the control
surface.

This might not be so bad for applications that use SDP for signalling, but
any app that uses something other than SDP for signalling necessarily views
SDP as the API surface, since there is no other way to tell the browser
what to do.





>
>
>
>  Maybe I'm wrong, but I'm guessing what you're saying will sound like.
>>  "my use case (legacy interop) is the most important and my solution (SDP)
>> is the best solution for everyone and I know better because I've been
>> working on it for longer".  Hubris?
>>
>
> No, you've misunderstood pretty much everything I said. I'll summarize in
> fewer words.
>
>
You called everyone who doubts the SDP API naive and full of hubris, and
now you're telling me I'm misunderstanding pretty much everything.


> My point is that we need to solve these problems one way or another, and
> SDP isn't really the reason it's difficult.
>

One problem is that this is a very difficult to use API for web developers.
 And SDP is at the heart of that problem.  Lots of people have said so, and
why, in great detail.  Do you really believe all of them are naive and full
of hubris?


>
> But by incorrectly deciding that SDP (or offer/answer, depending on who
> you listen to) is the reason it's hard, we're trying to throw legacy
> interop out the window for very little gain.


I think this is the real issue at hand:  You value legacy interop more than
a usable API.  Other value a usable API more than legacy interop.  You're
willing to sacrifice API usability for legacy interop, and they're willing
to sacrifice legacy interop for a usable API.  There are different groups
with different needs and different perspectives.

I think we can have both legacy interop and a usable API, and there are
many ways we can achieve that.  But we've been asked to delay talking about
it until "1.0" is done.  So, we'll have to wait for further discussion.




> And, while not the only (or even main) consideration, legacy interop has
> significant value. It would be a shame to destroy that value based on a
> misconception.
>
> These issues aren't hard because of SDP. These issues are hard because
> they're hard.


SDP as an API surface makes the API worse.  And API surface that didn't
require SDP would be a better API surface.  It's a fallacy to assume that
because we need legacy interop, we have to support it to the detriment of
of non-legacy interop use cases.  We could have both, if we wanted to
design an API for both.

Please try to realize that there are worlds of use cases beyond yours, and
there are lots of people with different needs than yours.  And please try
to listen to them rather than just calling them naive and full of hubris.


>
>
> /a
>