Chris Kranky

Recent Posts


When the man comes around

Chris KoehnckeChris Koehncke

godspeakGoogle’s Justin Uberti, who is one of the prime spokespersons for WebRTC, posted a message to the W3C community and basically told them to shut up and move on with all the chatter about changes to the WebRTC API. As Google has 100% veto power on WebRTC, I guess we can say “God has spoken.” Now move on.

Justin’s message to the group is politely worded (I’m saving this as a reference for the day when I become polite). Google recognizes that while the Internet community has some good ideas and Google has adopted some of them, we need to move the machine forward. So any talk about changing the WebRTC API just ain’t gonna happen right now. In addition, Google signaled that in the interest of speed, even some of the ideas they think are good, are gonna get sidelined. What’s important is — speed.

While I’m sure the grumblers will keep on grumbling. We all need to recognize that in fact speed is what we need to get this airplane in the air. The initial WebRTC API was straightforward, simple and had all the necessary elements to get going.

WebRTC is fairly rigid in some aspects and it wasn’t designed to be federated (namely that 2 WebRTC applications aren’t in fact supposed to talk to each other). WebRTC operates in an environment under the absolute control of a single application who is controlling most (but not all) of the levers.

The community would obviously like more granular control of the “levers” and indeed some of the queries make total sense. However, with increased complexity, comes the potential to screw things up. If I’m developing a WebRTC application, I’m gonna sit like a donkey if I think the API is continually going to change.

Good call by the ever polite Mr. Uberti. Get on it with folks, I’m waiting.

 

Comments 4
  • Marc Abrams
    Posted on

    Marc Abrams Marc Abrams

    Author

    I totally agree, except the devil is in the details. One thing I’m personally worried about is the debate concerning putting SDP and Offer/Answer in the various browsers.

    It’s taken many years for the teeming masses of SIP implementers to get to a BASIC level of interoperability, most having trouble with SDP, so I can see the same thing derailing WebRTC. I think leaving it to the implementors, not the browser vendors, is the right thing to do. If you need SDP and Offer/Answer for SIP interworking, then creating the right interoperable code can be done in Javascript, which lets the implementer tweak things without having to beg or wait for changes from the browser vendors. This will speed adoption up quite a bit.

    And, to the nay sayers, there are now TWO independent working implementations of SDP and Offer/Answer in Javascript… one from Hookflash and one from Microsoft. It can be done.

    So, it IS time to move on. Just don’t burden the browsers with buggy, incompatible SDP implementations that take years to debug and fix. That will derail WebRTC more than anything else.

    marc.


  • Tsahi Levent-Levi
    Posted on

    Tsahi Levent-Levi Tsahi Levent-Levi

    Author

    I am with you on this one Chris.

    People may whine about WebRTC APIs, but by the looks of it there are more vendors who churn out WebRTC POCs, products, services and demos than there are VoIP companies doing any such thing with any other VoIP technology. In my book, that’s good enough.

    Or as the saying goes – perfect is the worst enemy of good.