W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Discussing new API proposals

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 17 Jul 2013 12:29:51 +0000
To: Roman Shpount <roman@telurix.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C317FB8@ESESSMB209.ericsson.se>
On 7/16/13 7:26 PM, Roman Shpount wrote:
> Stefan,
> Thank you for stepping up to the discussion.
> As API stands right now it is incomplete until SDP definition is
> finalized and it is clearly specified what SDP modifications are allowed
> and their meaning. I think this group has underestimated the amount of
> effort required to complete this task. Until this is done, we are
> nowhere near being around the corner from complete API. In addition to
> this, I believe we still have large feature gaps such as, support for
> BUNDLE (if no-plan is implemented this is a large API change),
> capabilities support, and ability to change constraints. Taking all of
> this into account we are still in the proof of concept stage and can be
> years away from completion, unless we dramatically change the
> functionality scope and how API design is approached.

I agree that defining SDP use is most important, and we're waiting for 
IETF to do their homework. I can see signs of progress there now.

> I have expressed my opinion about what, at least from my point of view,
> is the shortest way to 1.0 specification:
> http://lists.w3.org/Archives/Public/public-webrtc/2013Jul/0169.html This
> proposal is not ideal, and it does reduce the potential functionality
> available via API, but it does it by reducing number of undefined things.

The current approach for 1.0 is to use SDP, but if someone contributes a 
(detailed) proposal that takes us faster to the goal of a stable spec, 
maintains functionality and still would be possible to translate to/from 
SDP, then I think people would listen. My personal view is that we 
should get to a stable 1.0 ASAP (and therefore I would like to change as 
few assumptions and design choices as possible), and if there are things 
that make that faster we should consider them. That said, the devil is 
often i the details, and something that looks simpler at surface can 
prove to take a lot of effort when you start getting into the bits and 

> _____________
> Roman Shpount

Received on Wednesday, 17 July 2013 12:30:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:49 UTC