Stefano Mazzocchi wrote:

>>What the Java Apache Server Framework Is
>>----------------------------------------
>>
>>It's a design methodology that allows design reuse as well as code 
>>reuse between different server projects. These projects gain the 
>>advantage of software reuse and the simplicity of developing/managing 
>>only the different logic. 
>>    
>>
>
>This is what Avalon was supposed to be 5 years ago and this is what we
>should have it to be.
>
>Those who want Avalon to be something else are free to fork it 
>
Stefano, your post is lousy swordsmanship but great leadership. As one 
of the forkers you speak of, only *outside* of Avalon where I belong, I 
need to give you a view from outside where we live.

We want to use it. We are using it. We love it, as it is truly a great 
concept in action. But what we are looking for is a common set of 
interfaces and patterns. But instead, we find a near-common set (read: 
all different) and swordplay swordplay swordplay. And more swordplay. 
And no common language yet, even though it is sooooo close, not because 
one isn't possible, but because that would take all the fun (swordplay) 
out of the place. If only we were here for the fun!

Your proposal to remove the implementations and leave the patterns and 
agreed upon call signatures will no doubt inspire even more great 
swordplay. But the fact is that until it happens, container madness will 
prevail and the knights are in charge. Remove the sub-projects and the 
Avalon becomes Avalon once again. Avalon is about the pattern, not the 
knights, or even the battles, even though it would never exist without them.

The court of King Arthur *has a* knights training ground. Not *is a* 
knights training ground. The battles are still important, but they are 
not the essence of the court. Has a versus Is a. Aggregation versus 
Inheritance. Seems so close, but a world of a difference as a pattern.

Really all you are asking for is SoC for Avalon itself. Spock would +1 
if he were a committer.

Reply via email to