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

Cullen Jennings <fluffy@cisco.com> Thu, 20 October 2011 00:46 UTC

Return-Path: <fluffy@cisco.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 6A3CC11E80BA for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_MED=-4, 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 FkHyK1-CBsUj for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 17:46:33 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 40F5311E80AF for <rtcweb@ietf.org>; Wed, 19 Oct 2011 17:46:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=7664; q=dns/txt; s=iport; t=1319071593; x=1320281193; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vUS2gFACLJZZWtrqwTjFxid09dIhUAKe9Qv76tYtJIU=; b=TzaokT8YEENJlAaQm6CMYms95h/qLH2vMN6JamrFBtYo5aUl7iMmCfHB 3bq3xF5Bu51rRhJYO1/LWOrx6X1IidHDr9Fbq2gThKiF+YC+ZAcy7F33T G4S3AoYtoSgNRj02iuHmRRCNWf6ckpTtBxHfq5eewHQYnv5h40qED/1tb w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsUFAH9un06tJV2Z/2dsb2JhbAA8BQOmR4EAgTuBBYFuAQEBAQIBAQEBDwEnLQcLBQkCCwc/GwwwBhMZBQSHXgiXdAGeTwKEbReCNGEEiAKLfIUqhQeHRQ
X-IronPort-AV: E=Sophos;i="4.69,375,1315180800"; d="scan'208";a="29660577"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 20 Oct 2011 00:46:32 +0000
Received: from [192.168.4.106] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9K0jTC6020510; Thu, 20 Oct 2011 00:46:31 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>
Date: Wed, 19 Oct 2011 18:46:30 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A8B9BC4-D6DB-4E7D-9472-E36E8D8B66AB@cisco.com>
References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org>
To: Dan York <dan-ietf@danyork.org>
X-Mailer: Apple Mail (2.1251.1)
Cc: rtcweb@ietf.org
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: Thu, 20 Oct 2011 00:46:34 -0000

Dan, totally agree, my goal has been able to have a nice little example that shows setting up communications in a browser in simple little HTML / JS example. I'm like how you make calls from the a browser on iphones. You just put a tel URL on your web page and it works. Unfortunately I think that is too simplistic for what we need but I view that as the level of simplicity to strive for. 


On Oct 19, 2011, at 6:20 , Dan York wrote:

> Folks,
> 
> I need to rant. I've been lurking on this list from the beginning but with a new job I haven't been able to really keep up with the volume of messages... and every time I get ready to reply I find that others like Hadriel, Tim, Neil, Tolga or others have made the points I was going to make... 
> 
> But I find myself increasingly frustrated with the ongoing discussions and want to ask a fundamental question:
> 
> - WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?
> 
> Is it for:
> 
> 1. Telephony developers who are tired of writing code in traditional languages and want to do things in new web ways;
> 
> 2. Web developers who want to add real-time comms (as in voice, video and chat) to their existing or new web applications;
> 
> 3. Both 1 and 2.
> 
> If the answer is #1, then I think everything is going along just wonderfully.  We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI area are all used to and understand just fine.  Heck, let's just all end the discussions about a signalling protocol and agree on SIP... get the browser vendors to agree on baking a SIP UA into their browsers... and call it a day and go have a beer.  Simple. Easy. Done.
> 
> And the only people who will ever use it will be people who work for RTC/UC/VoIP vendors and random other programmers who actually care about telephony, etc. 
> 
>  But that's okay, because the people who do use it (and their employers) will be really happy and life will be good.
> 
> 
> If the answer is #2, then I think we need to step back and ask - 
> 
>    HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK?
> 
> Here's the thing... in my experience...
> 
>     99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!
> 
> Never have.  Never will.  (In fact, I may be understating that. It may actually be 99.99999%.)
> 
> If they are with startups, they want to build nice bright shiny objects that people will chase and use.  They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over).  If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.
> 
> And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.
> 
> They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page.  Their interaction with telephony is more along these lines:
> 
> "Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"
> 
> And the thing is... they can do this **TODAY** with existing proprietary products and services.  You can code it all up in Flex/Flash. You can write it in Java.  You can use Voxeo's Phono.  You could probably do it in Microsoft's Silverlight.  I seem to recall Twilio having a web browser client.  A bunch of the carriers/operators are starting to offer their own ways of doing this.  On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.
> 
> Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers. 
> 
> It can be done today.  Now.
> 
> The drawback is that today you need to have some kind of applet/plugin/extension downloaded to the browser to allow access to the mic and speakers and make the RTC actually work.  So you have to use some Flash or Java or something. AND... you are locked into some particular vendor's way of doing things and are reliant on that vendor being around.
> 
> THAT is what RTCWEB can overcome.  Make it so that web developers can easily add RTC to their web apps without requiring any downloads, etc.  Make it do-able in open standards that don't lock developers in to a specific product or vendor.
> 
> But if we are targeting "web developers", that is need we need to satisfy... and we need to understand that they *already* have ways to do what we are allowing them to do.
> 
> If we come out with something that is so "different" from what "web developers" are used to... that requires someone to, for instance, understand all of what SIP is about... that requires a whole bunch of lines of code, etc.... well...
> 
> ... the web developers out there will NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% who don't care about telephony"... they will simply... not... use.... RTCWEB!
> 
> They will continue to use proprietary products and services because those work in the ways that web developers are used to and they make it simple for a web developer to go add voice, video and chat to a web app.  Sure... they will still require the dreaded plugin/extension, but so be it... the "open standard" way is far too complicated for them to look at.
> 
> And all the work and the zillions of hours of writing emails and I-Ds that this group has done will all be for nothing.  Well, not nothing... some of the telephony-centric developers will use them.  But the majority of the web developers out there may not because there are other simpler, easier ways to do what they need to do.
> 
> 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?
> 
> </rant>
> 
> Dan
> 
> -- 
> Dan York  dyork@lodestar2.com
> http://www.danyork.com/   skype:danyork
> Phone: +1-802-735-1624
> Twitter - http://twitter.com/danyork
> --------------------------------------------------------
> All comments and opinions are entirely my own and have no connection whatsoever to any employer, past or present. Indeed, by tomorrow even I might be disavowing these comments.
> --------------------------------------------------------
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb