avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Under Promise, Over Deliver
Date Thu, 20 Jun 2002 18:08:25 GMT

Nicola Ken Barozzi wrote:

> Berin Loritsch wrote:
>> In my experiences with computing, the company's motto that impressed me
>> the most was Be, Inc.  Jean Louis Gasse' (sp?) was a genious for
>> promoting
>> the mindset of "Under Promise, Over Deliver".  For a commercial company
>> it really hampers the marketing department, but for an OSS project it is
>> the only mindset to have.
>> There are some key obstacles that seem to be in our way of achieving
>> this goal:
>> 1) Over design, under simplification
>> 2) Big ego, small content
>> The big ego, small content has already been hammered on, so we will try
>> to keep the signal to noise ratio down.
>> So far the most productive thread we have had was the "Fresh
>> Perspective",
>> as I finally got what Stephen and Peter were pushing (although at first
>> it was just Stephen).  There is a lot to like in it.
>> Our biggest problem is Over Design, Under Simplification.  The job of a
>> *usable* framework is to enable things to be done that otherwise could
>> not be done.  Avalon 4 does this quite well.  There are some things that
>> does not sit well with me in the track we are on for A5.  They are
>> listed
>> below:
>> 1) The container specification is becoming quite complex.  The
>> complexity
>>    is hoped to be made up for by a "ContainerKit", but if someone wanted
>>    to discard the container kit and create their own container from
>> scratch
>>    it is approaching the level of needing a company to finance the
>>    proposition.  This is not good.
>> 2) We are pushing *more* of the burden of design, thread safety issues,
>>    etc. on the component developer.  This is a *bad* choice.  ColdFusion
>>    4 tried to automatically handle the locking of CF script variables,
>>    but did a poor job of it.  Their solution was to offload that
>>    responsibility to the page developers.  By CF 4.5, we had a product
>> that
>>    needed to be revamped to explicitly handle locking of variables.  We
>>    are making the same mistake regarding pooling of components.
>> 3) If anything, we want to make it *easier* to use.  Even better we want
>>    to make it *easier* to use correctly.  While it is a design goal to
>>    encourage good practices and discourage bad practices, we can't all
>>    do that at the interface level.  People follow examples, good or bad.
>> Now documentation and examples are something we can do in A4.  However
>> it
>> is the type of examples that need to make sense.  We need to demonstrate
>> *why* something is bad (performance, maintenance, scalability, etc.),
>> and
>> how to correct it *easily*.  Something like the J2EE BluePrint document
>> would be best.  We need to demonstrate how certain designs just work
>> better,
>> and aren't that much more difficult to do.
>> Some things are difficult to do.  Pooling components is a valid
>> proposition.
>> You could have fewer instances of components than threads of execution
>> (as
>> opposed to the more common case in Cocoon where there are multiple
>> instances per thread of execution).  However, removing the release()
>> method
>> has incredible consequences on existing code for only a little ease in
>> the container.
>> As Benjamin Franklin said, "They that give up essential liberty to
>> obtain a
>> little temporary safety deserve neither liberty nor safety."  While
>> it has more to do with patriotism than with development, it still
>> applies.
>> Unless we provide a fundamentally *better* approach that does not tax
>> our
>> users, the proposed approach is flawed.  It is like when England raised
>> taxes on American soil without giving them representation in parliament.
>> The Americans eventually revolted, casting all things English aside.  It
>> wasn't until much later that America and England could stand each other
>> enough to resume trade relations.
>> This is *not* what we want for Avalon.  Any freedom we remove *must*
>> be replaced with something better.
> *clapping hands wildly*
> I think that this can be our vision for now.
> Do you mind if I put it in the Avalon docs?
See prev. email for reasons.
Cheers, Steve.


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message