- From: Adam Roach <adam@nostrum.com>
- Date: Fri, 19 Jul 2013 12:49:53 -0500
- To: Peter Thatcher <pthatcher@google.com>
- CC: IƱaki Baz Castillo <ibc@aliax.net>, Cullen Jennings <fluffy@iii.ca>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
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
Received on Friday, 19 July 2013 17:50:35 UTC