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

Hi K,

On 20/07/2013 1:23 PM, K Moon wrote:
> A standard API is a promise from the browser makers that they aren't 
> going to change everything around in the next point release, just 
> because they thought of a better way to do it.

     Pay close attention to what you just wrote. On the one hand you're 
asking us to publish a mediocre 1.0 and fix it in 2.0. On the other 
hand, you're saying that standardization ensures that 2.0 won't "change 
everything around".

     There are some mistakes (the current API contains many of them) 
that cannot be undone without "changing everything around". You can 
evolve APIs by adding new methods, but you cannot work around existing 
design decisions like exposing SDP or the Offer/Answer mechanism. You 
are stuck supporting them for life. In short: you can't have your cake 
and eat it too.

     I understand where you're coming from. You're talking about using 
different Javascript libraries off Github. Eventually one of them 
reaches the end of the line (designs itself into a corner) and you jump 
onto another one without the backwards-compatibility baggage of the 
original. The problem is that WebRTC is baked into the browser. APIs 
that are baked into the browser have no alternatives. There is no 
dropping backwards compatibility. There is only one DOM api and if you 
don't like it, there is no alternative to jump to.

> Meanwhile, if a browser comes out with a great new way of doing things 
> (Pointer Events might be a good example), I'm happy to support that, 
> too. And if that browser lets me do things I can't do on other 
> browsers, I'm going to be pushing to have those browsers support that 
> new way, too. That's the beauty of browser competition. But show me 
> the code; win me over with your great implementation, don't just keep 
> talking about how things would be so much better if everyone would 
> just open their eyes and follow you. Give me something I can use, not 
> locked behind a separate download.

     This is the kind of wild west mentality that prevailed prior to 
W3C's creation. You can't on the one hand advocate going back to this 
and on the other hand ask W3C put out conflicting "standards" (Chrome 
will publish one, IE another, Safari a third).

Gili

Received on Sunday, 21 July 2013 20:46:51 UTC