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 <adam@nostrum.com> Fri, 19 July 2013 17:25 UTC

Return-Path: <adam@nostrum.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 4C29911E8174 for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.527
X-Spam-Level:
X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 Och8k-CRL2+c for <rtcweb@ietfa.amsl.com>; Fri, 19 Jul 2013 10:25:21 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 09F2F11E8147 for <rtcweb@ietf.org>; Fri, 19 Jul 2013 10:25:20 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r6JHPG1T074495 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Jul 2013 12:25:18 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <51E97677.1020902@nostrum.com>
Date: Fri, 19 Jul 2013 12:25:11 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@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> <CABkgnnXa-eTzRHcLMnHam4c+1D9kkvRwi9=V-9P43+p+pKE_sw@mail.gmail.com> <CA+9kkMCjt2UHFynLqwns0J0f5ZtnxtMX3ppzR66e5q_rJ9D5Ug@mail.gmail.com>
In-Reply-To: <CA+9kkMCjt2UHFynLqwns0J0f5ZtnxtMX3ppzR66e5q_rJ9D5Ug@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------090605080100040702020800"
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
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 17:25:22 -0000

On 7/19/13 12:07, Ted Hardie wrote:
> On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>
>     Negotiation is a hole.  A vast, soul-sucking, waste of time.
>
>
> Even if you have the same javascript application downloaded, you will 
> have disparate capabilities in the environments into which it is 
> downloaded (browser/os/codecs/media sources/available network 
> capacity).  Getting set intersection and preference order for those 
> capabilities is something that applications actually want. You may be 
> able to move the pain of that around, but it isn't a waste of time.

I can't +1 this hard enough. I certainly don't want every javascript 
application that makes use of the WebRTC API to independently discover 
that mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to 
unusable if you try to send it more than 320x200 video, and then try to 
solve that problem.

Again and again, for every permutation of phone and operating system 
version.

Yeah, someone has to do this kind of characterization, and some of it 
can be done real-time if you're interacting directly with the operating 
system. So... maybe we could add yet another API to WebRTC to allow 
applications to build this functionality themselves rather than counting 
on them characterizing the systems they care about and blowing up on the 
ones they don't.

But, honestly, any course of action that relegates this to the 
applications seems to have the dual properties of forcing it to be 
implemented hundreds of thousands of times while making the actual user 
experience worse.

/a