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

Roman Shpount <roman@telurix.com> Thu, 20 October 2011 18:37 UTC

Return-Path: <roman@telurix.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 311FC21F8BB6 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 11:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 g-yhya9p1PeK for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 11:37:54 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 95A1A21F8BB3 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 11:37:54 -0700 (PDT)
Received: by gyh20 with SMTP id 20so3728421gyh.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 11:37:54 -0700 (PDT)
Received: by 10.236.183.52 with SMTP id p40mr4074534yhm.19.1319135874055; Thu, 20 Oct 2011 11:37:54 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id d5sm15129469yhl.19.2011.10.20.11.37.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 20 Oct 2011 11:37:53 -0700 (PDT)
Received: by qadc10 with SMTP id c10so780360qad.31 for <rtcweb@ietf.org>; Thu, 20 Oct 2011 11:37:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.32.138 with SMTP id j10mr15942646pbi.81.1319135872964; Thu, 20 Oct 2011 11:37:52 -0700 (PDT)
Received: by 10.68.47.40 with HTTP; Thu, 20 Oct 2011 11:37:52 -0700 (PDT)
In-Reply-To: <CA+9kkMB_t6g9oh0zxtYDgOkJ3+smjW7GCCS05M9werbGS_kLYg@mail.gmail.com>
References: <CAD5OKxvBMt_EDzPprGeFGGTPS0z3DXAz9YJPDqCwF6HKuPrpFg@mail.gmail.com> <CA+9kkMB_t6g9oh0zxtYDgOkJ3+smjW7GCCS05M9werbGS_kLYg@mail.gmail.com>
Date: Thu, 20 Oct 2011 14:37:52 -0400
Message-ID: <CAD5OKxtS8u5H0nq4vq6=OV7J157=SrHRVs6PyJOZyyL_AqeR1g@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Ted Hardie <ted.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="bcaec52163d11e57ed04afbf4173"
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:37:55 -0000

On Thu, Oct 20, 2011 at 2:12 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> 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*.
>
>
I think I do not quite agree about "dead simple". "Dead simple" is not the
goal, the goal is simple as possible without jeopardizing the functionality.
As I mentioned before, adding "tel:" or "skype:" or "sip:" URL to a document
is already dead simple, but does not get you much.

The good way to develop such APIs is to develop a minimal set of primitives
that will allow the desired functionality. If from application building
experience a set of operations emerge that are complex to implement, but
often used, add them as convenience API functions. Starting from convenience
API usually gets you to a point were you get an API with 10 different ways
of doing almost the same thing (see sound APIs in Linux or Timers in
Windows).

Standard signaling protocol is a convenience feature for RTC. It is heavily
dependent on the matching server component. It replicates functionality that
is already available and requirements for it are unclear.
_____________
Roman Shpount