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

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

From: Martin Steinmann <martin@ezuce.com>
Date: Fri, 19 Jul 2013 19:55:59 -0400
Message-Id: <81C8BA82-1296-4F03-B1E2-308813F9D968@ezuce.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>

On Jul 19, 2013, at 6:18 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> On 19 July 2013 15:05, Martin Steinmann <martin@ezuce.com> wrote:
>> The aggressiveness of argument on this list is perplexing.
> You are new here I see.  I don't find it perplexing, as much as I find
> it disappointing and exhausting.

I have been on this list for a long time, likely like many others who are wondering what is going on. 

Does anyone really expect Google and Mozilla to change their implementation just because some other companies want to build, for the most part, proprietary peer-to-peer systems?  To transform the multi-billion dollar telecoms industry into a Web economy you need legacy interop and a consistent and simple (high-level) API that facilitates interoperability.  From an economic perspective this is very simple.  

Elevating this discussion from a pure technical argument and into the real world would require those who say they represent browser vendors to actually state what standard these browsers would support and by when and how these standards would facilitate interop.  Are the IE, Lync, and Skype teams all on the same page?  Such a commitment would make a real difference and resonate with the industry at large.

What we the users and developers of apps really need is consensus and commitment for browser support, desktop and mobile.  I have seen the Skype team propose CU-RTC-Web, but would IE support it? How about Lync?  And would Microsoft support the industry making the implementation available in open source and with a royalty free patent grant?  What is the argument to convince Google and Mozilla to re-implement?  Without thinking this through the best API proposal is pretty useless and the argument mainly academic.

The current draft spec is very nicely setup to meet the larger objectives towards broad adoption.  To counter that will require an all-encompassing proposal and committment and not just another technical spec thrown into the ring.  


>> 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.
> I'm not sure that "build on existing" an axiom I've encountered
> before.  It's certainly a social pressure (buy, don't build, etc...),
> but it's not a rule.  If it were a rule, it would be a pretty major
> impediment.
>> 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.
> There have been no votes [1] in the time that I have been part of this
> working group.  If this were a democracy, I'd say something along the
> lines that the chairs are subject to the will of the
> people/participants, but it's a little more nuanced than that in this
> case.
> [1] http://www.w3.org/2005/10/Process-20051014/policies#Votes
Received on Friday, 19 July 2013 23:56:29 UTC

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