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

[Adam Roach <[e-mail]>]

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.



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

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

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

/a