Re: Poll for preferred API alternative

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
afresh.

-Prakash

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
>
>