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>
- Re: [rtcweb] RTCWeb default signaling protocol [w… Iñaki Baz Castillo