avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Under Promise, Over Deliver
Date Thu, 20 Jun 2002 14:49:40 GMT


Leo Simons wrote:
> On Thu, 2002-06-20 at 15:27, 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?
> 
> 
> as long as it is under TODO or somethin. I don't really want anything
> about A5 mentioned in a prominent place on the site. Also, it'd not be
> so cool if we said on the main site "we have big egos, little content,
> and too much design".
> 
> Hope you see what I'm getting at...

Ok, you're right, I meant to keep the "vision", not the "mea culpa"; 
I'll commit it to xdocs for reviewing, but not push it to the site yet.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message