W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: Poll for preferred API alternative

From: Prakash <prakashr.ietf@gmail.com>
Date: Tue, 4 Sep 2012 22:15:17 -0700
Message-ID: <CADa6zEbu8D5A_-_PVjawtdX5BvmOrcJ80a1DFzOpvgCMhRC-Zg@mail.gmail.com>
To: public-webrtc@w3.org
Prefer option 1. After watching all the debates about no sdp vs sdp (almost
a year ago), no jsep vs jsep, and many others, reasoned and deliberated by
this group, it doesn't make any sense to throw it all out now and start


On Tue, Sep 4, 2012 at 8:24 AM, Eric Rescorla <ekr@rtfm.com> wrote:

> On Wed, Aug 29, 2012 at 5:30 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
> > The discussions of Aug 28 showed that there are people with differing
> > opinions on the structure of the API this WG should design.
> >
> > Most of the work in front of this group currently is dependent on a basic
> > decision between those two approaches - the issues to be resolved (for
> > example congestion control and RTP stream mapping) are in many cases
> present
> > in both proposals, but the API specifications that need to be developed
> look
> > a lot different.
> >
> >
> > It is not efficient use of the groupís time to work out detailed,
> > implementable proposals that then are thrown away because of a later
> > decision - nor is it a working environment conducive to inspiring
> > volunteers.
> >
> > The two alternatives, as the chairs see them, are the following:
> >
> > 1) Continue with a design based on the PeerConnection object, using SDP
> as
> > part of the API, roughly in the style of the current API description.
> My preference is for option 1.
> The decision between a low-level API (e.g., CU-RTC-Web) and mid-level
> API (e.g., the current API) is to a great extent a matter of moving
> complexity between the browser implementor and the site implementor.
> In general, given the small number of browsers and the large number of
> sites, this should be pushing us in the direction of having the
> complexity in the browsers. We have already seen that it is possible
> for relatively naive site implementors to build stuff on the current
> API without having to learn much about VoIP. This would clearly not be
> the case with a low-level API absent the existence of some
> high-quality library, which then itself creates another problematic
> dependency.
> It is of course possible that these considerations would be outweighed
> if there were a large class of use cases that were possible with a
> low-level API but not the existing API. However, MS hasn't really
> presented any such use cases. Given that, and given that it will
> certainly cause very significant delay (at least a year and probably
> more) in terms of having a completed standard, I don't think it's a
> good idea to start over with a low-level API.
> -Ekr
Received on Wednesday, 5 September 2012 05:16:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC