Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

Harald Alvestrand <harald@alvestrand.no> Wed, 19 October 2011 14:03 UTC

Return-Path: <harald@alvestrand.no>
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 C5C2821F8C1D for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 07:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.567
X-Spam-Level:
X-Spam-Status: No, score=-110.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wqYy2SOuVgQG for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 07:03:26 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE5221F8BDB for <rtcweb@ietf.org>; Wed, 19 Oct 2011 07:03:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6A3E439E163 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 16:03:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-ca8jpZRTzn for <rtcweb@ietf.org>; Wed, 19 Oct 2011 16:03:24 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id A718539E162 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 16:03:24 +0200 (CEST)
Message-ID: <4E9ED8AC.8070406@alvestrand.no>
Date: Wed, 19 Oct 2011 16:03:24 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>
In-Reply-To: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
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: Wed, 19 Oct 2011 14:03:26 -0000

Dan,

thanks for the rant!

Unfortunately, I'm finding that I agree with almost everything you wrote 
- and STILL find that I see arguments on both sides of the "lowlevel API 
/ ROAP" divide.

On 10/19/11 15:20, Dan York wrote:
> So I go back to the question - who are we building RTCWEB for?
>
> Is the goal to enable the zillions of web developers out to be able to 
> use real-time communications in new and innovative ways?  Or is it 
> solely to make it so that VoIP/UC/RTC vendors can make a softphone in 
> the browser that calls into their call center software?
>
> RTCWEB *can* enable both... but to me it's a question of where the 
> priority is.
>
> The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so 
> simple and easy that web developers will choose to use it over 
> Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?
>
> If the answer is yes, we win.  Open standards win. Maybe we upgrade 
> from having a beer to having champagne.
>
> If the answer is no, what are spending all this time for?
>
While I like beer, I'd like there to be champagne :-)

But - in my reading, the "lowlevel API" requires wisdom in both the 
browser and in Javascript about "all the RTC stuff"; the "ROAP" API 
requires wisdom in the browser about the same stuff.

The "lowlevel API" (once it's fully fleshed out) will (presumably) allow 
the Phonos of the world to offer an API as compelling as what they have 
today.

The "ROAP API" hides the complexity in a different way; so far, people 
have argued that everything we have listed as scenarios can be done in a 
ROAP-like fashion, and this API can be offered without requiring the 
assistance of additional libraries.

Do you see a compelling argument that enables you to say that one path 
is better than the other?

                      Harald