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

[Bernard Aboba <[e-mail]>]

Dan --

Great rant.  However, if I understand you correctly, your concerns relate to the WEBRTC APIs being developed within W3C, not to the work going on in IETF RTCWEB.  Personally, I don't expect the W3C APIs to be used directly by Web developers in most cases.  Rather, I expect developers to use higher level libraries that will, among other things, check for the available browser functionality, enabling applications to run both on browsers that support RTCWEB, as well as ones that do not but support the alternatives you mention.  Given that, I'm not expecting that developers will find RTCWEB any harder to use than the alternatives, because the differences will be abstracted away. 

However, if we are opening the RANT queue, I do have a concern that relates to IETF RTCWEB.  And that is the number of dependencies that are piling up, even for simple scenarios.  Fundamentally, many of the issues we have been talking about arise from the need to support peer-to-peer media.  This is what drives the need for ICE (so recipient can authorize sending of media),  end-to-end security (e.g. to know/authorize where P2P media is going),  and to some extend DoS and congestion control functionality.   While I understand the need for P2P support, we do need to avoid imposing all of these dependencies in simple client/server scenarios.  For example, if all a developer wants to do is send media and signalling down a websocket, many of the concerns arising from P2P media evaporate.  When operating within the "single origin" model, it should be possible to maintain a very high degree of legacy interop, with no requirements for ICE, e2e security, etc.  

From: [e-mail]
Date: Wed, 19 Oct 2011 09:20:18 -0400
To: [e-mail]
Subject: [rtcweb] A plea for simplicity,	marketability - and... who are we designing RTCWEB for?



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  [e-mail]
http://www.danyork.com/   skype:danyork
Phone: [phone]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb