Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Iñaki Baz Castillo <ibc@aliax.net> Tue, 04 October 2011 10:14 UTC

Return-Path: <ibc@aliax.net>
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 35C6721F8C92 for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 03:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.635
X-Spam-Level:
X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 VyCvZ2RrRIVD for <rtcweb@ietfa.amsl.com>; Tue, 4 Oct 2011 03:14:52 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B907621F8C8D for <rtcweb@ietf.org>; Tue, 4 Oct 2011 03:14:51 -0700 (PDT)
Received: by vws5 with SMTP id 5so266520vws.31 for <rtcweb@ietf.org>; Tue, 04 Oct 2011 03:17:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.23.4 with SMTP id i4mr892662vdf.514.1317723476219; Tue, 04 Oct 2011 03:17:56 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Tue, 4 Oct 2011 03:17:56 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Tue, 4 Oct 2011 03:17:56 -0700 (PDT)
Date: Tue, 04 Oct 2011 12:17:56 +0200
Message-ID: <CALiegfn=1gfEbGfL7iUymuUj0W1fuJwvUg74b_4n_TioB2xJbg@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
Content-Type: multipart/alternative; boundary="20cf307ca582b658b804ae766797"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
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: Tue, 04 Oct 2011 10:14:53 -0000

2011/10/4 Ravindran Parthasarathi <pravindran@sonusnet.com>:
>  I understand that jquery or libjingle library may act as an alternative
but it is far better in case signaling protocol is provided in the browser
platform itself.

I've never said that jQuery is an alternative for rtcweb, where/when did I
say that?
jQuery is a JS library for easy management of the page DOM and some JS
effects.

> As a RTCweb developer, the standard signaling protocol helps as follows:
>
> 1) there is no need to peek into each license of jquery library and
understand the terms and conditions for developing the real-time
application.

Not a good argument IMHO.

> 2) No need of every browser user to download jquery library from each
website. Unlike few number of E-mail provider (gmail, yahoo, hotmail), the
real-time application provider will be huge. But number of browser is going
to be countable and not as much as real-time websites are.

Will you ignore my arguments again and again?? What about all my text
explaining that a native signaling protocol built-in the browsers means that
for fixing any bug all the browsers in the world must be fixed and all the
humans in the world must update their browsers?? could you please NOT ignore
this argument again and just reply to it?

Also, you say "No need of every browser user to download jquery library from
each website". As said above jQuery is not about rtcweb but about pure
JavaScript and HTML/DOM (maybe in a future it includes a signaling protocol
for rtcweb, who knows...). But for your information, today *every browsers*
download jQuery library from each website including it, everyday, and that
is NOT a problem (regardless how much you insist on that as if it was a
problem). It's NOT a problem, it's an advantage as each web developer can
include the version of jQuery he desires for his application, and update it
when needed without requiring a new version of Firefox or Chrome in all the
web visitors! Is it so hard to understand this Ravindran? Will you reply
something interesting to this? or just "no need of every browser to download
the javascript library"?


> 3) I heard from web developer about browser compatible jquery development
story which is same as SIP interop issues.

Press F5 or Ctrl+R and you get a new version of jQuery (if the web developer
included it). But if the bug is in the web browser (as in the *native*
signaling stack you propose) then the user must update his web browser.

Please, DON'T ignore this argument again.

> 4) Perform of the native signaling protocol will be better than jquery
library. Please note that plugin is forbidden in RTCWeb client (browser).

You should demostrate that a signaling protocol in JavaScript is a bad idea
rather than speaking about performance issues with no real tests and code. I
have *real* JS code implementing signaling and there is no performance
issues at all. JavaScript is very optimized in most of the browsers.

> IMO, Jquery will not solve the indented problem.

Of course not! jQuery is not a rtcweb signaling protocol! I just put jQuery
as a real example of a very extended JS library that lot of web sites
include and millons of web browsers download every day (without that being a
problem as you insist).

> The main motive for RTCWeb standard signaling is rapid real-time
application in browser platform by any web developer and there should be no
need of signaling expert in each website development team.

Again: any good and extended JavaScript library will do the same by hidding
signaling complexity to the web developer. No need for forcing browsers
vendor to include,mantain and upgrade a native signaling protocol.

Anyhow, IMHO this discussion is a no-go.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>