W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

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

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 12:42:38 -0700
Message-ID: <CAJrXDUHiNHOn9zMa9hNiRYd+t2ZNDZ4BZ8CFk-iG5UA8wYKThA@mail.gmail.com>
To: Adam Roach <adam@nostrum.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 Fri, Jul 19, 2013 at 12:06 PM, Adam Roach <adam@nostrum.com> wrote:

> On 7/19/13 13:47, Peter Thatcher wrote:
>> I think this is the real issue at hand:  You value legacy interop more
>> than a usable API.
> This. *This* is why I've told you that you're misunderstanding everything.
> Don't take offense, just go back and read more carefully. I never said
> anything that implied that legacy interop is more valuable than a usable
> API. It's a nice strawman for you to build up and tear down, but you are
> arguing with a fictional character who is not me when you do so.
> What I'm trying to point out is that these goals are not at odds with each
> other. Your statement above implies that you have taken it as given that we
> can't do both -- that there is a tradeoff here to be made.

If you take that as a fundamental principle, then I can see how nothing I
> say makes any sense.
> But they're not mutually exclusive goals. Keep that in mind, and go back
> to re-read what I've written.
You are claiming that there is no tradeoff between API usability and legacy
interop.  If that is the case, then why have we designed such a terribly
unusable API?  If we can have an API with both legacy interop and
usability, then why didn't we create that API?  If we can make an API that
serves both sides (roughly, "web developers" and "legacy interop") well,
why have we picked an API that only serves one well?

I do believe that we can have an API that provides both good usability and
legacy interop, and that can server both sides (and even more sides) well.
 But is most assuredly not the API we've designed so far, and it's not the
API we're headed toward (at least not with "1.0").  I have hope for the 2.0
API, but let's not kid ourselves.  The 1.0 API picked a side and ran with

> /a
Received on Friday, 19 July 2013 19:43:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC