- From: Eric Rescorla <ekr@rtfm.com>
- Date: Tue, 4 Sep 2012 08:24:07 -0700
- To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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 Tuesday, 4 September 2012 15:25:27 UTC