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 Fri, Jul 19, 2013 at 4:55 PM, Martin Steinmann <martin@ezuce.com> wrote:

>
>
> 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?


What is a "proprietary peer-to-peer system"?  And why should the WebRTC API
not allow it?

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.
>
> --martin
>
>
> >
> >> 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
>
>
>