- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 18 Jul 2013 15:02:55 -0400
- 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. Gili
Received on Thursday, 18 July 2013 19:03:37 UTC