4k is big talk in the video world, but is it practical for a WebRTC application? Let's find out.
When the man comes aroundChris Koehncke
Google’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.