Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00

[Iñaki Baz Castillo <[e-mail]>]

2011/10/21 Dan York <[e-mail]>:
> Bingo... I think we want to create the conditions where a hundred different
> JavaScript libraries will bloom as developers try out new and innovative
> ways to bring real-time communications directly into the web browsers and
> weave it into the fabric of the web.

> Yes, some (many? most?) of those libraries will suck badly ... but over time
> I believe the "jQuery of RTCWEB" will emerge from somewhere and suddenly
> people all over will be baking RTC directly into web apps using the
> proverbial less than 20 lines of code.

Hope we *all* agree on this since this is the ONLY way to go in WWW
world (IMHO). It's time to move on and avoid useless discussions about
signaling protocols in the wire.

In summary:

1) Let the browser vendors to be that: "browser vendors". Don't force
them to be SIP/VoIP experts. Well, they must deal with ICE/TURN/RTP,
but that's unavoidable in RTC and this is about RTC.

2) Let the complexity and innovation to the developers who build
JavaScript libraries implementing all the low level stuff and their
own custom singaling protocol in-the-wire (of course with the
colaboration of the web/websocket server, which must implement such
protocol in some language).

3) Let the end users to make use of the libraries provided in point 2,
so they can write a RTC code "in 20 lines".


Point 2 means that all the innovation and quality depends on
JavaScript (in browser side) and PHP/Ruby/Python/Java/.Net/[...] in
server side. This is freedom. Point 3 means success. This is the key
in WWW.



-- 
Iñaki Baz Castillo
<[e-mail]>