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

Peter Thatcher <pthatcher@google.com> Fri, 19 July 2013 18:47 UTC

Return-Path: <pthatcher@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8164511E8145 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 11:47:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.724
X-Spam-Level:
X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sl3vPagdgJVe for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 11:47:52 -0700 (PDT)
Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8F49A11E818D for <rtcweb@ietf.org>; Fri, 19 Jul 2013 11:47:52 -0700 (PDT)
Received: by mail-pd0-f182.google.com with SMTP id r10so4597712pdi.27 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 11:47:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SAaka8Xu0QikonOGz5I3gNumRSvSYX1iAhkUcBM0LF8=; b=I/k0uan9An2SsMVf2pN8AwIJaieSNQXurUxlZGqGLDnkivHHK29kGpMJpyMuhNM+lF T/CNg1rmB8C/XJtCQqcanrLtuTK12Mc1L2l1Itn8PdTu8hvgag0b/wL5vLXAUE7G948F /H4MlklFz0EKwLqXIneukSmAcapLIexsnfAKv8WNNQ1y0RVLOcStmafaZ7ZdtIdhDPaS wHQ5qxNm4lLwYVPW71QPF5Z55p1SX0TE4ZFwt9yWXVI2gFbMKCWb8nKi3upalWdVqPh5 IV9iBNzNsuqcrHNdHxeP6xfkWTykuOAHe2BrvYO5bGBHjGtBOWagL7X0Hs6/qiXFvBPr T3pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=SAaka8Xu0QikonOGz5I3gNumRSvSYX1iAhkUcBM0LF8=; b=d9SNlBrTf6dsp92GmZQdlTgJ6QV8EhaEwA94328c/bVfb5Iuhw5yV4VXtDDPE7zAYF 1VcWaUk0YhpXlmKF3zQn7QAOWNuhsKnnOstD3QXNn2BYJ43IPrLWdPCaJovsMZ9zaFAF 3U64ZPyBgM/hme/obL3Ls9p5r4d4g5afLJ4Md0PZ4spUKaIGJ6DwC+uzhOuq4E46OCkY aCB5j5BRinn6vMSjrrbrZkW02HCTpTHhqZZVVijQzgx5c+FAJWVZpdaukFh6XUJ80zwX 4cWnrL847DvqOOATjUQgORVr+S3hPrJ2668UUYaG2VdMPEQmlNC1GsK/iKslbAD/2WmF 88Xw==
X-Received: by 10.68.104.196 with SMTP id gg4mr18930858pbb.25.1374259672063; Fri, 19 Jul 2013 11:47:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.78.195 with HTTP; Fri, 19 Jul 2013 11:47:10 -0700 (PDT)
In-Reply-To: <51E97C41.5050208@nostrum.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com> <CABcZeBPa4wBS8pYq=0wesMOfL6TkeC7QGAZ8pWwOcnkhkJqWfA@mail.gmail.com> <CAJrXDUFxo8P8wxh8jX3019yPQOuwQ0eVdsFmRXsbWdWinnc5oA@mail.gmail.com> <CABcZeBOTKpmFC34waqZ4kA-P8t+E6yY9gX1JFCHhsBH0+CF-Qw@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30BC0F@ESESSMB209.ericsson.se> <CAD5OKxtKLMf_d=8GSMrqfNhDHPe9MFP2ZTKzZHFn9CyMr-gSVQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30C833@ESESSMB209.ericsson.se> <CAD5OKxvGfkgRp6tXwbOu_kVteHiBBqsyR5ixH18FMKjCNGO8VQ@mail.gmail.com> <1447FA0C20ED5147A1AA0EF02890A64B1C30CD1E@ESESSMB209.ericsson.se> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <AE1A6B5FD507DC4FB3C5166F3A05A484213E41E7@TK5EX14MBXC265.redmond.corp.microsoft.com> <C50FDAD5-492C-4A83-AD6D-464242FB4A05@iii.ca> <CALiegfneUj=kzDjR_E1=S-bqAajaPUE3f_A2g8oGriFyPhamPA@mail.gmail.com> <51E96B5B.2050302@nostrum.com> <CAJrXDUFtPwHNznRHYgMpSr8U04Y+toDHubJ5fK-2qtnsURtL7g@mail.gmail.com> <51E97C41.5050208@nostrum.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 11:47:10 -0700
Message-ID: <CAJrXDUE05ZGeH42z3r82V2cfZhu7oA3ODYwbtcqiEr+R0LB66Q@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Content-Type: multipart/alternative; boundary="047d7b6705b9953e7d04e1e1c354"
X-Gm-Message-State: ALoCoQkLATVQze8Z1voUjn6f8I2Oi9urEsU72NCAk99nzV5EJ1W0ykqmMt6wVhtGP6CmvPsv22q/PTvB+4/n6qoecRjaAak2LFpCGyqvE+LlallXG/QwbgNW6oBAUVlQpuJsZkb9aqszxJVzFfK2mQer34kUY2SfuHykIWvou3kZr5oT8tWMBRwyMRqk0Dia9/Ozh+8JEuwf
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 18:47:53 -0000

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
>