Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

On 21/07/2013 6:51 AM, tim panton wrote:
> On 20 Jul 2013, at 05:06, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net> wrote:
>
>> Martin Steinmann [mailto:martin@ezuce.com] :
>> 	The aggressiveness of argument on this list is perplexing.  In every collaborative effort you have to respect and build on what already exists.  If you violate this basic rule, you loose legitimacy to participate.  If I remember correctly there was a vote on this subject some time ago and I don't think it is the chairs being inflexible.  All they are trying to do is prevent total chaos and I applaude them for that.  Keep up the good work.
>>
>>
>> 1. The aggressiveness is a reaction to certain individuals, including chairs, who appear to be entirely unwilling to listen to even unaligned third-party developers who have found major problems with the existing specification.
>>
>> 2. There is a whole lot of "building on what already exists" in all of the proposals, even the CU-RTCWEB proposal, which builds on GetUserMedia and SRTP and all sorts of good things.
>>
>> 3. There wasn't a vote. There was a poll, and a decision made 9-10 months ago before we had input from other third party developers and before we saw just how long it would take to get even minor changes to SDP through the multitude of interested working groups at IETF (MMUSIC, CLUE, perhaps AVTEXT, RMCAT, and others). Now we have this information, and working prototypes of alternatives, and a handful of influential people with their fingers in their ears shouting I'M NOT LISTENING and I CAN'T HEAR YOU UNTIL THE 1.0 SPEC IS FINISHED. Even though some of the input they are getting is explanation of why the "1.0 spec" A) won't be finished nearly as soon as was originally projected (that's easy to prove, as that date has already passed) and B) doesn't meet the actual needs of real developers.
>
> I think there is a legitimate case for the " I CAN'T HEAR YOU UNTIL THE 1.0 SPEC IS FINISHED" line, it has a real possible benefit but it comes with a price.
>
> The benefit is that it gets a 1.0 out the door sooner.
>
> The price is that to get the benefit, we will have to dump all the 'features' that can't be defined by reference to an
> _already_  existing, ratified RFC or other normative standard.
>
> Are we willing to go through the feature set and requirements with a sufficiently large axe to make that possible ?
>
> The last year has shown that we can't have an ever-expanding feature set with definitions to be set by other work groups and still meet an aggressive deadline.
>
> Tim.

     Look, the fact of the matter is the majority of Web Developers (and 
surprisingly even Telecoms) are against the API in its current form: 
https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0

     I'm willing to bet that the vast majority of Web Developers would 
happily throw the (unrealistic) deadline out the window in return for a 
properly-designed API.

     If the Working Group (consisting of mostly Browser Vendors and 
Integrators) are happy with the current API, let them release it under a 
different name... but please don't hijack an API meant for Web 
Developers. It doesn't make sense to take the requirements of Browsers 
Vendors and Integrators and tell Web Developers that they should be 
happy to use it.

Gili

Received on Sunday, 21 July 2013 18:41:11 UTC