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?
>
-1
See prev. email for reasons.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
