avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject RE: [Summary] Avalon 5 ComponentManager interface
Date Wed, 12 Jun 2002 15:01:30 GMT
> > > > you are right - everything gets a little bit more complicated.
> > > > 
> > > Yes, and this is the thing that worries me - I know a lot of people 
> > > saying "Avalon is too complicated" and this makes it even a 
> > little bit 
> > > more complicated,
> > 
> > hmm. Is it more complicated?
> As Vadim said in a comparison of Cocoon and Struts: Cocoon developers
> come from the "pattern hell" school of thought. (That was a point
> against Cocoon, if anyone missed it.)
> Worth thinking about, as I have seen some people here accusing
> Cocoon of not following patterns cleanly enough.
> As a matter of fact, I think we scare the shit out of most people
> with the complexity of the framework already.

yup. Which is why it would be good to make it simpler, which I believe
these changes will do, as I tried to point out.

> Patterns within 
> patterns... It is not whether there are patterns or not - it is 
> the fact that you have patterns of patterns, and you must somehow
> grasp them all.

"patterns of patterns" ... that's a good way to describe it =)

I got started with avalon by writing a nifty horror called XCommander.
I'm quite sure I didn't understand all of those patterns then, though.

We should separate what you need to grasp to work with avalon, and what
you need to know to work with it perfectly. Just like there's many
levels of java programming skill (you don't need to know clasloaders to
write an applet that does tic tac toe).

> So I completely understand Carsten. We will lose users. I see
> before me someone saying "F*** it. (1) They are obviously not committed
> to API stability, (2) just about when we've finally learned to use
> the framework (given how complex it is that may be a while), the next 
> change will come along, (3) the cost of maintenance and keeping up 
> with that will kill us. Let's roll our own framework."

yup. The thing to do is to change this perception so that it is clear
that (1) is not true, that the changes in (2) will make using the
framework both easier and simpler in the end, and to be very sure that
(3) will also not happen (ie backwards compatibility in a realistic

> If it is more complicated or not does not matter - what matters is
> what it is *percieved* as.


Another thought: having users on a development list means we will have
more perceptions like this. Having a user list would remove some of
these concerns.

- Leo Simons

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