avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepanossov, Kirill" <kstep...@lehman.com>
Subject RE: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Date Wed, 27 Nov 2002 17:00:17 GMT
> Stepanossov, Kirill wrote:
> > Committers, if this accepted, could you still leave 
> different "toolkits" for
> > building customized containers available ?
> Why does everybody here think that COP and inheritance don't mix? Who 
> said that?

Well... from user's point of view the best 'framework' would be blackbox
framework. Meaning a user would prefer to see a "subsystem" through a number
of interfaces without mandatory understanding functionality of underlying
classes. In this case the "extension" of blackbox framework would be
composition and implementaion of framework interfaces. Inheritance is a way
to go when you have a whitebox framework and must understand internals of
framework classes to extend them. 

> > Either they may offer too much
> > or too little. Personally, would prefer to have several 
> "toolkits" for
> > building the majority of possible containers + a few 
> containers as examples
> > of constructing containers from those "toolkits"...
> The history of this project showed pretty evidently how COP-patterns 
> applied to community building creates fragmentation and isolation and 
> friction. Toolkits might be technically easier to use to achieve user 
> goals but are bad for the evolution of a coherent and focused 
> development community.
> Which one do you prefer: a technical solution that works now 
> but might 
> leave you alone in the future because the maintainer decided to do 
> something else, of a technical solution that imposes some work on you 
> but will be maintained for that point on by an active community?

I have an impression that a lot of recent "shaking" in Avalon could be
caused by underestimation of what Avalon means for a lot of users. The real
value of Avalon is not an implementation of end-user  product such as any
kind of container. No. Every container you, guys, write will die sooner or
later - when you say that Phoenix has been rewritten several times it means
you wrote several completely different containers but named them the same.
And it is a way it is going to be. The value of Avalon is a set of design
solutions which emerge from one iteration and decided by Avalon community to
be worth to move to the next container. 
The first step Avalon went through was designing of lifecycle interfaces and
their extensions, what  is basically over and pretty much stabilized. The
second step is identifying of common design solutions of any container
hosting components with lifecycle interfaces. The way to document those
common design solution I called here "toolkits". Ideally, it would be
several sets of packages with interfaces but not implementation. Then, any
user would "bet his ass on Avalon" as volatility will be minimized.
Unfortunately, this second step encounter a lot of issues. The most
important one is that some most active Avalon developers do not realize what
is the real value of Avalon. They seems to use a certain container for
implementation of other real word products and therefore reluctant to move
forward. As a result of it many good new things are being vetoed as
incompatible with existing containers and/or branches appear. I still
remember as Avalon 5 proposal was "thrown away" ...
Please, guy, realize that the primary goal of Avalon may be other than
developing a container for your own project... we, users, are watching and
waiting results which WE can use....



> It's your ass you're betting on Avalon, do you have the energy to 
> maintain a one-man-show toolkit if the original showman leaves or is 
> kicked out?
> Wouldn't you be more confortable on a solution maintained by several 
> different individuals? wouldn't it be harder to see the development 
> effort disappear?
> It's yous ass, dude, think about it.
> -- 
> Stefano Mazzocchi                               <stefano@apache.org>
> --------------------------------------------------------------------
> --
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@jakarta.apache.org>

This message is intended only for the personal and confidential use of the designated recipient(s)
named above.  If you are not the intended recipient of this message you are hereby notified
that any review, dissemination, distribution or copying of this message is strictly prohibited.
 This communication is for information purposes only and should not be regarded as an offer
to sell or as a solicitation of an offer to buy any financial product, an official confirmation
of any transaction, or as an official statement of Lehman Brothers.  Email transmission cannot
be guaranteed to be secure or error-free.  Therefore, we do not represent that this information
is complete or accurate and it should not be relied upon as such.  All information is subject
to change without notice.

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