Re: Poll for preferred API alternative

On 9/4/2012 11:24 AM, 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.
>
> 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.

I also prefer option 1 for these reasons, and I'll add (as I mentioned 
here) that the issue of JS libraries being out-of-date (and usually with 
no clear update mechanism, or varying levels of support - and varying 
levels of knowledge of the underlying network protocols) concerns me 
greatly.

When first discussed a long time ago, the jquery-like idea was 
interesting, but the nail in the coffin for me on that was the stats on 
how often sites update the copy they grabbed.

That doesn't mean you couldn't have mid and low level APIs within the 
browser; but if so there's no reason to abandon or significantly delay 
the current work towards a mid-level API.  (For that matter, early on 
I'd proposed a high-level API, in the browser in addition to ROAP/JSEP,  
as an option for allowing even easier use of WebRTC).

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

I agree; there was repeated probing for use-cases this enables that 
aren't covered by the current approach (or that would require this level 
of change), and none were forthcoming.  If there are use-cases that 
weren't mentioned or some additional functionalities needed, we can look 
how they can be handled within the current framework (perhaps adding 
optional flexibility to some aspects).  However, I would think if there 
were any major use-cases enabled by the proposal they would have been 
offered in response to the questions; instead we heard the opposite.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 5 September 2012 02:40:39 UTC