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

Re: Discussing new API proposals

From: cowwoc <cowwoc@bbs.darktech.org>
Date: Thu, 18 Jul 2013 15:02:55 -0400
Message-ID: <51E83BDF.1080407@bbs.darktech.org>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 18/07/2013 7:02 AM, Stefan Håkansson LK wrote:
>        To me, that means that 93% of the community is unsatisfied with the
> existing API. The poll goes on to mention that 54% of them define the
> existing API as "Horrible/intolerable for 1.0". That's a lot of hate
> (not just mild dislike).
> One thing is to agree on that disliking (or stronger) something. But
> agreeing on a design replacing the current one can take a very long time.

     Which is why we're frustrated that the WG has wasted months 
suppressing the community's legitimate concerns instead of addressing 
them. You will have to go down this road. The sooner you begin, the better.

>>        So to reiterate: 1.0 is not around the corner and the existing API
>> is unacceptable in its current form.
> My personal opinion is still that the best we can do is to finalize 1.0
> based on the current design. And that includes specifying all the things
> needed to be able to do interoperable implementations (and perhaps scope
> down if needed). If we start from scratch things could take a long time.

     We're not starting from scratch. Most of the work to date has gone 
into getting WebRTC to run, period. Refactoring an API on top will be an 
order of magnitude easier.

     We're not throwing away the guts of WebRTC, we're simply shifting 
the API on top of it. The only exception that I am aware of is replacing 
the Offer/Answer mechanism, but we're not even sure that we need to go 
down this road (to be discussed).

>>        It is extremely difficult to propose alternatives unless/until you
>> document your design decisions and link them to the use-cases that
>> justify them.
> I don't get this. If the current design is so broken as claimed, then
> the design is probably based on bad decisions - so what would be the
> gain in writing them up in a document?

     How would we be able to differentiate between the good and bad 
decisions until their justification is documented? We can't read minds.

>    BTW, I think the decisions made
> can be tracked down by reading existing documents, minutes of meetings
> and mail list traffic (in IETF and W3C space).

     Stefan, we're talking about about thousands of emails here. The 
goal here is to have 1-2 individuals put together an executive summary / 
design document so 100+ individuals don't have to read through these 
documents. Dumping this task on the community is a form of stonewalling.

Received on Thursday, 18 July 2013 19:03:37 UTC

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