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

[Harald Alvestrand <[e-mail]>]

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