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

Iñaki Baz Castillo <> Fri, 21 October 2011 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A190721F8C82 for <>; Fri, 21 Oct 2011 06:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7c30eX3eUOhK for <>; Fri, 21 Oct 2011 06:10:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 17BEC21F8C81 for <>; Fri, 21 Oct 2011 06:10:34 -0700 (PDT)
Received: by vws5 with SMTP id 5so3477719vws.31 for <>; Fri, 21 Oct 2011 06:10:04 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id a11mr14299213vdg.1.1319202604774; Fri, 21 Oct 2011 06:10:04 -0700 (PDT)
Received: by with HTTP; Fri, 21 Oct 2011 06:10:04 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Fri, 21 Oct 2011 15:10:04 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Dan York <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "<>" <>
Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Oct 2011 13:10:34 -0000

2011/10/21 Dan York <>:
> 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