[EDITED]
Stephen McConnell wrote:
>
> Nicola Ken Barozzi wrote:
>
>> Berin Loritsch and Nicola Ken Barozzi 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 OS project it is
>>> the only mindset to have.
>>>
>>> There are some key obstacles that can be in the way of achieving
>>> this goal, for any project:
>>>
>>> 1) Over design, under simplification
>>> 2) Big ego, small content
>>>
>>> The big ego, small content is typical of OS, and the community should
>>> always remember to keep the signal to noise ratio down.
>>>
>>> When discussion is overheating, remember the golden rule:
>>> write a mail, give it all you've got, then reread it and delete it.
>>> Start over, any finally try to get your point through, if you
>>> still have a point, that is.
>>>
>>> Another 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, and it's our committment
>>> to make it ever better.
>>>
>>> 1) Some specifications can becoming quite complex.
>>> The complexity sometimes can be reduced by creating a better set
>>> of helper classes or implementation
>>> Acid test: If someone wanted
>>> to discard the new kit and create their own from scratch
>>> it would be approaching the level of needing a company to
>>> finance the proposition. This is not good.
>>>
>>> 2) 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.
>>>
>>> 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 must always do. 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, because of the impact on existing use.
>>>
>>> Example: 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.
>>>
>>> Bottom line:
>>>
>>> Unless we provide a fundamentally *better* approach that does not
>>> increase the conceptual and implementative burden on 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 feature we remove *must*
>>> be replaced with something better.
>>
>> Do you mind if I put it in the Avalon docs?
>>
> -1
> See prev. email for reasons.
Is this better?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
