- From: Ted Hardie <ted.ietf@gmail.com>
- Date: Thu, 30 Aug 2012 10:43:29 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: public-webrtc@w3.org
Hi Martin, On Thu, Aug 30, 2012 at 9:54 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > It seems that a recurring theme in discussions is the cost to developers. > <snip of clarification that this is not about the poll question> > -- > > What has not been properly recognized in the debate is the presence of > a trade-off. Possibly this is because everyone in the discussion is experienced enough that this is a given? That engineering involves trade-offs is pretty old news, after all. >Building applications that have parts outside of your > control sucks. Sure, it's a natural consequence of trying to do > anything more than the most trivial application. That doesn't > diminish its suckitude when it comes to writing and maintaining > software. For me, that's always been the attraction with open source > software: when it breaks, *I* can fix it. > > 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). > > CU-RTC-Web attempts to address that trade-off rationally. Yes, there > is more work to get set up. The advantage is in how applications are > empowered to deal with problems. Find a problem and there's a good > chance that you can fix it. > Well, there may be a good chance that *you* can fix it. But what you're trading off is power for the power user versus ease of use for the larger development community. Perhaps even more problematic is that it is only a specific species of power user that's going to be able to take advantage of that ability--those with a deep knowledge of the network internals that go into making WEBRTC work. A power user of javascript whose main focus is building a dating site, a casual game, or a virtual car lot will probably not want to take advantage of the power you wish to hand them; they will want the standard API to work with a minimal amount of effort. For someone building an application for which WEBRTC is not the main focus, the ability to re-write a library to fix a problem is neither going to be particularly practical nor necessarily their desire. So your trade-off may be rational for you, but I personally don't believe that it is rational for the development community that's built the games/user experiences that have already been demonstrated with the current approach. In other words, I agree with you that we're making a trade-off. But I personal believe that the current approach makes that trade-off in a better way for a larger community than CU-RTC-Web. regards, Ted Hardie
Received on Thursday, 30 August 2012 17:44:05 UTC