Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

Peter Thatcher <pthatcher@google.com> Mon, 08 July 2013 13:57 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 A482121F9C87 for <rtcweb@ietfa.amsl.com>; Mon, 8 Jul 2013 06:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 H5Z6zLLQjRrD for <rtcweb@ietfa.amsl.com>; Mon, 8 Jul 2013 06:57:33 -0700 (PDT)
Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id C38FC21F9C81 for <rtcweb@ietf.org>; Mon, 8 Jul 2013 06:57:28 -0700 (PDT)
Received: by mail-pa0-f53.google.com with SMTP id tj12so4424656pac.12 for <rtcweb@ietf.org>; Mon, 08 Jul 2013 06:57:28 -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 :content-type; bh=5ViZzIlguF64Vvj8aJAVH04eAFRwX1WylWaMfu8FM6E=; b=VEhp6BJJJdrb1kuNCAZdr2Jwqqoyyy7062t4xc7my19yRcyhwirvejvLegwzZUpj4+ whAkKLYLv+/SfX31gv+fDsKdrMSaeA+icA4wg65SmmGtOwawEhOHcSuvrQCdZleVspWQ NmxKQrou6cTGnuvORgWldx/BQCEQDiZrEVf5iwT9/te09CiexFHfqUsTlDjftp4XZozM DmIzj7AjcJeCBSrnfaVUlBk0v8tOaPtHnhuKB1YAgDvf2KeS8sru0cHARRuNtN7tKH22 q3aSCkbXqJuP6v1xlIAFLrPilZMarJwy5UxnM7Y5wqjHVsn/qowe6E3oc43XRCQcFB91 adNQ==
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 :content-type:x-gm-message-state; bh=5ViZzIlguF64Vvj8aJAVH04eAFRwX1WylWaMfu8FM6E=; b=IpyN/yZHUfPu0BvMaGUCSyFBLPMdDtmhW5w4WrGNAG2YjwweTzDzw6APPnFlOt2KNE cDjwnncCWwxLMqb0G1IVtFrUwu+dhCXMIlNt0kWZhvFb1N+s2FNerwuLQDY7yErtGZ+B genZDPf3dP4Xpacx8ejiOGR3E15iLx+8uwI0dk8ovKk4QsWCJLIuO7dlk7O1M4vu/zvh ghN7esxNwuNIRpEM5JD0ZO/RWI9gzalZmllVcrvION4ohDB2i6gSzqC3S7RX/zy6CUVq X7qEE9PSo6fxkvQnolxju470m9FHCGgQbUU/E0vlowfGR17gtsMSoeb5jCsfbZW4r4sb 3wbg==
X-Received: by 10.66.141.4 with SMTP id rk4mr22823409pab.127.1373291848492; Mon, 08 Jul 2013 06:57:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.78.169 with HTTP; Mon, 8 Jul 2013 06:56:48 -0700 (PDT)
In-Reply-To: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com>
References: <CAJrXDUGMohpBdi-ft-o_uE7ewFkw7wRY9x7gYEncjov7qi-Bew@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 8 Jul 2013 06:56:48 -0700
Message-ID: <CAJrXDUEPy9Gpnu+On8tEwQbSy7k+Z6E5rRrrJVVcxAkMFP7FwQ@mail.gmail.com>
To: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c39d18cd80e304e1006c57
X-Gm-Message-State: ALoCoQladXxw2IOTtDdUTb4i0dJPDY7gLafIV3tTWugVgVDKS51+e3cks5yCMX0DIAyZmsq/DyrpvnIFmJfBavL6ya3Q3pn8Lz4agKOEXIQpA8gUR4g+RrFa8Q9wHFF6G6vxdgrIJVZVJNpD/e5BfRWILJU8NPLto4AL7j2FXj+W9xn/Uq3XEap3Fnfc7C7+vspCABeGWaBN
Subject: Re: [rtcweb] 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: Mon, 08 Jul 2013 13:57:34 -0000

Just in case it is missed elsewhere in the thread, I'll reply directly to
my own message.  It was pointed out to me that I made a mistake with my
addition.  The first line should have read:

61% "Good for simple Stuff"        39% "Bad for simple stuff"

Sorry about that.


On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <pthatcher@google.com>; wrote:

> After about a week of input, and feedback from 19 developers doing a wide
> range of things using the WebRTC API, we have some data about their opinion
> of the current API.
>
> *Short answer*:
>
> 61% "Good for simple Stuff"    49% "Bad for simple stuff"
>  6% "Good for advanced stuff"      94% "Bad for advanced stuff"
> 46% "Good/OK/tolerable for 1.0"    54% "Horrible/intolerable for 1.0"
>  7% "Good/OK/tolerable long-term"  93% "Need a better API long-term"
>
>
> In general the attitude is *"It's OK for simple stuff but bad for
> advanced stuff",  *and *"We can tolerate it for 1.0, but we need
> something better for 2.0".  *But the majority of the feedback was against
> it even for the 1.0, so the last one is a bit of a stretch.
>
>
> *Long Answer*:
>
> I had to interpret the results a little to fit into these buckets, so if
> you don't like the interpretation, you're more than welcome to interpret
> your own results from the raw data:
> https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1
>
>
> There seem to be 4 or 5 different camps:
>
> Camp #1:  Doing very simple things, doesn't touch the SDP.  Everything is
> fine, except they might have things they want to control but can't.
>
> Camp #2:  Does somewhat more advanced things, touches the SDP a little,
> has pain, anticipates more pain, would like something better, but thinks
> this is OK for 1.0.
>
> Camp #3:  Is trying advanced things, is touching the SDP a lot, and really
> feels pain.  Wants something better, and might tolerate this API for 1.0,
> but not for long.
>
> Camp #4:  Doesn't want SDP or O/A in the API at all.  Has a very strong
> dislike for it.  Won't tolerate it, even for 1.0.  The IETF and W3C should
> be embarrassed for even suggesting such a terrible API.  It's better to go
> back to the drawing board (if you think those words are strong, go read the
> spreadsheet or mailing list!)
>
> Oh, and of course, for completeness, we should describe Camp #0, which
> didn't have any input in this feedback:
>
> Camp #0:  I've used SDP for years and I'm very comfortable with it.  Using
> SDP as the control surface really helps my use case, which is legacy
> interop.  Defining an API without SDP would be too much work, and probably
> fail.  Look at what happened with SDPng!  Supporting all these advanced use
> cases doesn't seem worth it.   If developers are doing that much advanced
> stuff, they can learn to munge SDP.  It isn't that bad.
>
> (By the way, I'm not a member of Camp #0, so I may be a little off in my
> description of it.  If any member of Camp #0 would like to adjust that
> description, please feel free).
>
>
>
>
> *Suggested Next Step: Figure out what is needed for WebRTC++*
> *
> *
> As Cullen recently pointed out, we need to get a list of things developers
> want to be able to control in a future version of the API which could
> hopefully make developers happier Whether that future API is 1.0, 2.0, or
> 1.1 is an orthogonal question, but let's call it WebRTC++ for now.
> Clearly, they want a way to control things without SDP, and perhaps without
> O/A at all.  But what do they want to control?  We need a good list.
>
> I suggest we reach out more closely to the developers, and use their input
> to create not only a list of things they want to do, but a WebRTC++ API
> that fulfills those needs without requiring SDP munging.  I think we can do
> this in parallel with the current  API work without detracting from it
> (from the current work, that is).    Certainly there is plenty of energy
> from people interested in working on it (WebRTC++, that is).  Such parallel
> work would not only better capture the needs of developers, but could also
> improve the WebRTC (not ++) API  by incorporating ideas from it.
>
> So far, such activity has been frowned on, perhaps out of fear that it's a
> threat to the current work.  But I think it can be done in a way that
> doesn't threaten anything, and even learns from and builds on the valuable
> input we are receiving from developers.  The alternative is to ask all
> these developers to wait an indefinite amount of time and munge SDP like
> crazy until then, and that seems like a rather poor answer.  Therefore, I
> would support an exploratory effort at a "WebRTC++ API".
>
>
>
>
>
>
>
>