Re: [rtcweb] Why are we asking the wrong questions?

Ted Hardie <ted.ietf@gmail.com> Thu, 20 October 2011 18:12 UTC

Return-Path: <ted.ietf@gmail.com>
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 075FB21F8B4C for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 11:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.199
X-Spam-Level:
X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KGm4ECsRgfil for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 11:12:06 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A52B21F8B48 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 11:12:05 -0700 (PDT)
Received: by yxj19 with SMTP id 19so3693368yxj.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 11:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xweWm2fWlnawaUJbQgEXQRakkYo9Y2/9d+rWoU1mtEU=; b=CQ+LoD+0Rrge5vg8tn/iz+HDfDlSmn0kDJ6Z/HKhOD4NIJEDRXOp5MO+UljiHZIr6j sTf5A4nxKy/S+2FDhVXilukIGYyrQjHnYZ2R+5/Q10drQOQ0bTLxg+R2c7s665fe/b78 F1D8TtPRTR2/ENpwTk4kMN+T2eBETy62AuLbo=
MIME-Version: 1.0
Received: by 10.236.186.102 with SMTP id v66mr17272654yhm.108.1319134325197; Thu, 20 Oct 2011 11:12:05 -0700 (PDT)
Received: by 10.236.105.169 with HTTP; Thu, 20 Oct 2011 11:12:05 -0700 (PDT)
In-Reply-To: <CAD5OKxvBMt_EDzPprGeFGGTPS0z3DXAz9YJPDqCwF6HKuPrpFg@mail.gmail.com>
References: <CAD5OKxvBMt_EDzPprGeFGGTPS0z3DXAz9YJPDqCwF6HKuPrpFg@mail.gmail.com>
Date: Thu, 20 Oct 2011 11:12:05 -0700
Message-ID: <CA+9kkMB_t6g9oh0zxtYDgOkJ3+smjW7GCCS05M9werbGS_kLYg@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Roman Shpount <roman@telurix.com>
Content-Type: multipart/alternative; boundary=20cf30563e17dd4b9904afbee4a0
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Why are we asking the wrong questions?
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: Thu, 20 Oct 2011 18:12:07 -0000

On Thu, Oct 20, 2011 at 8:16 AM, Roman Shpount <roman@telurix.com>; wrote:

> First irrelevant topic is "We want something that will allow to setup a
> media call in 20 lines of JavaScript".


Perhaps it is time to review some of the drivers of the work here.  One of
the primary issues raised during the lead-up to the BoF was that embedded
interactive audio/video functions which could be achieved with plugins could
not be achieved without them.  Since the plugins varied (both among vendors
and over versions), that created an interoperability problem and hindered
deployment (some people would not download the plugins, others would not
upgrade deployed version, not all plugins were available on all
platforms--the usual litany).

To compete with a plugin, however, it cannot be significantly harder to
write an RTCWeb-capable  application than the equivalent in the popular
plugins.  If it is far more difficult or far less clear how to do it, the
effort fails.

How you achieve that simplicity may still be up for debate, but I don't
think the goal is wrong.   If you do, I am curious why continuing along the
plugin path is not simply the right answer for your goals.

regards,

Ted

PS.  In a spirit of openness, I freely admit to having concerns that the
"1000s of JS libraries" vision will either fail to emerge, fail to be
maintained, or will result in sufficient confusion among app writers that it
fails the "far less clear how to do it" test.  To avoid that, I think you
have to standardize the JS libraries' base capabilities in a way that makes
it just as simple to put the base capabilities into the browser--with the
resulting advantages in download power and energy already described, not to
mention the system simplicity issues Harald raises, and with which I agree.
But that issue (standard library functions versus standard browser
functions) is less important than the goal: make it dead simple to include
interactive audio and video functionality in a web page/app *without a
plugin*.