- From: Anant Narayanan <anant@mozilla.com>
- Date: Thu, 30 Aug 2012 14:17:51 -0700
- To: public-webrtc@w3.org
On 8/30/12 9:54 AM, Martin Thomson wrote: > The problem with a black box is that there is nothing I can do to fix > it. All my experience with browsers suggests that it takes a long > time before you can be certain that the bug has gone away for good. > Bugs introduced in 2001 are only now on a small enough portion of the > web that they can be effectively ignored (if you are feeling > aggressive). I think this statement is misleading because it implies that the very same problem does not exist with third party JS libraries. Sure, if you discover a bug in the JS implementation of ICE, you might be able to fix it, but I can safely assert that over 90% of the users of that library won't even know of the existence of such a bug, let alone know how to fix it, or worse, know that they need to update their includes because a critical fix was released. I trust browser update mechanisms far more than the popular systems used by web developers today to manage their JS library dependencies. ... > This requires relatively little code to build as it turns out. But > it's all javascript. I'm a big proponent of moving as many things out of the browser and into JavaScript as possible (heck, I've made several statements in the past supporting the ability to encode and decode media entirely from JS, encouraged by projects like "Broadway", the pure JS H.264 decoder). However, following numerous discussions with folks both inside and outside of Mozilla, I have come to conclude that in this particular case of network setup and teardown, doing so would be a mistake and a disservice to the web community at large, simply because of the nature of a network API. Equating an ICE implementation to a library like jQuery, or even Broadway, is naive at best. -Anant
Received on Thursday, 30 August 2012 21:18:22 UTC