- From: Salvatore Loreto <salvatore.loreto@ericsson.com>
- Date: Fri, 7 Sep 2012 17:03:17 +0300
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- CC: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
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