Re: On the subject of complexity

+ 1

Sent from my iPad

On 30 aug 2012, at 19:45, "Ted Hardie" <ted.ietf@gmail.com> wrote:

> 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 18:51:51 UTC