Re: Poll for preferred API alternative

On 9/4/12 6:24 PM, Eric Rescorla 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.

I concur with Eric below statement

/Salvatore


> 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 Friday, 7 September 2012 14:03:47 UTC