IETF Logo Mail Archive

Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Peter Thatcher <pthatcher@google.com> Thu, 27 June 2013 05:24 UTC

Return-Path: <pthatcher@google.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 59AD021F9B4D for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 22:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.774
X-Spam-Level:
X-Spam-Status: No, score=-1.774 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_URI_CONS7=0.306]
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 JOQ6hbGjewqP for <rtcweb@ietfa.amsl.com>; Wed, 26 Jun 2013 22:24:06 -0700 (PDT)
Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id AEA0121F9BFF for <rtcweb@ietf.org>; Wed, 26 Jun 2013 22:24:06 -0700 (PDT)
Received: by mail-pb0-f53.google.com with SMTP id xb12so401967pbc.40 for <rtcweb@ietf.org>; Wed, 26 Jun 2013 22:24:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Mb5VJhlq9ynZrb0glGXRQQMbdERBnKagJD/f8QnuZ8E=; b=GMScMwKHEx5Kb991WaanGaiGnSd9S/w2hJVu05L9CacXzRKAmTiOdht/eHvMZJAMDP PQTabuLPf/GTG5A6vsWNMtUWpg8tlm1RRrWoAs/mEFSxhcOHwcmy3S5yvdVA8S8VcLAp 7vNfEk/Rk4TLOSAblSND7/yB1vfxTX8YOQU4AcwQrfMFhYntCMibE/2H2OJnP8R8UG/F wtjgO5nw+ixbF8XPZ4iZmzEkwQVU1IKwte8BJFX97prvYiSw6siSruloolAjXVVOIoIv gaSDQEMX6Gpw2lPWGDB86KEoQ8BPEYvLTbel3oH2kkhn0n4s0CbGBHi4V1bYm1TfnYnz d9lQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Mb5VJhlq9ynZrb0glGXRQQMbdERBnKagJD/f8QnuZ8E=; b=MP9BAIqnxD0gY6tYZajaF0dgoPm/eAO17jJRGgqWRrCQg/7N1swMBspx2jCMCLQaNK Mswrhv2e1zy0NjdQl/Wm3gypiwGu94UkFciUlI6rzTVTRB9H74rJ/WzwHSe/PgZaD9kG Iomt/mcmu9kwTjKTBsq/svbFXdR6DuTLr/Sg9m7Cp0nxueNws/McX0L5yirFQYCZt+p+ P/CEC8K9P7VzCbsATuQ98ReU5oTwXiY6ENAhTZ0/I+AqwZtKaBnWfsahiCTMRXxYKG8+ oV8U/1ayrIfJ66a53uHplr6e5/TA3nmuLZ5ZIX5a2/K/jpmxAD0PVGrYjdt1xdJZ4nFk 1MdA==
X-Received: by 10.66.165.97 with SMTP id yx1mr4152611pab.82.1372310646362; Wed, 26 Jun 2013 22:24:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.216.163 with HTTP; Wed, 26 Jun 2013 22:23:26 -0700 (PDT)
In-Reply-To: <CAJrXDUHnECsdbb4yo9N1ZseQyaLGXviA+pOm15JW4Ofa9Vd3Yw@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com> <51C1D55D.6040905@hookflash.com> <BLU169-W225763F0847397377AA5AE93750@phx.gbl> <CAJrXDUHnECsdbb4yo9N1ZseQyaLGXviA+pOm15JW4Ofa9Vd3Yw@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 26 Jun 2013 22:23:26 -0700
Message-ID: <CAJrXDUGGizXvg-mhyGSNpJhSipPAtnXsqj0wVFEGPi_sBetCpQ@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: multipart/alternative; boundary="047d7b86c5289948ba04e01bf844"
X-Gm-Message-State: ALoCoQkVGBwEx6n1C9saX6Lg495NYikGn8OyadZEJgz1clln6SFFqwykb60YD/rZgjEmPrytEDh5UGKZvRNjqEKshQ8EmsOIIFxjUpgqUSlKOnQmAhbqLQHVPpPdKSIkepe235Y49Sc6Paj95ASYeGnjoqZ5AIq6a3r9/MIEd8y6XaJkP3f6C9bVm4B/FC6GtaIxMmjSodZG
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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, 27 Jun 2013 05:24:07 -0000

Sorry.  I meant to say " implement a "WebRTC 2.0" API, and then build the
WebRTC 1.0 on top of it by porting" rather than "implement a "WebRTC 2.0"
API, and then build the WebRTC 1.0 on top of it.  You could then port".


On Wed, Jun 26, 2013 at 10:21 PM, Peter Thatcher <pthatcher@google.com>wrote:

>
>
>
> On Wed, Jun 26, 2013 at 9:14 PM, Bernard Aboba <bernard_aboba@hotmail.com>wrote:
>
>> Robin said:
>>
>> "If provided a lower level API that works without SDP where the
>> individual network/media component wiring/attributes can be controlled, we
>> could create the same WebRTC API that exists today'
>>
>> [BA] I wouldn't require a shim to provide "the same WebRTC API that
>> exists today" because that API is very underspecified, so that it is not
>> possible to produce a set of conformance tests for it without reverse
>> engineering.  And of course, that reverse engineered specification would
>> only remain valid until the next set of SDP hacks invalidated it.
>>
>
> Once thing you *could* do (I'm not saying this is a good idea) is take an
> open source browser (let's pick Chrome) implement a "WebRTC 2.0" API, and
> then build the WebRTC 1.0 on top of it.  You could then port the WebRTC 1.0
> SDP code (for reference, it's here:
> https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc)
> on to the WebRTC 2.0 API.  At that point, you would have an "1.0 on 2.0"
> API that is the same as the "original 1.0" API, or at least as close as
> could possibly be done.  And at the same time, you'd have the 2.0 available
> to JS to use.
>
> Repeat that process for all (2) browsers that have implemented the WebRTC
> 1.0 API.  What could go wrong :)?
>
>
>
>>
>> So while the shim might provide a "similar high level WebRTC API",
>> holding WebRTC API 2.0 to a "bug for bug" compatibility standard is neither
>> feasible nor desirable.   The goal of WebRTC API 2.0 should be to deprecate
>> 1.0, not to increase the WebRTC API implementation barriers even further.
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>

v2.23.0 | Report a Bug | By Email