avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Summary] Avalon 5 ComponentManager interface
Date Fri, 14 Jun 2002 16:14:41 GMT
Leo Simons wrote:
> 
> > > > > 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.

If even a single committer on this list disagrees, I smell troubles.
Here you have two/three (Berin, Carsten and myself). Interesting enough
Cocoon is the biggest and most used project that uses Avalon and we
represent that community.

Of course we don't want to veto anything as we are here to help and to
shape A5 so that everyone is happy, but it should definately ring a
bell.

> > 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 sometimes used the term 'metapattern' to describe IoC and SoC. In
fact, MVC implements SoC.

> 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
> way).

Hmmm, simply by stating that every component must be ThreadSafe, you are
forcing every project that uses A4 to implement a ton of shitty glue
code around those inherently thread-unsafe components, just to satisfy
your elegance needs.

Talking about ways to piss people off, this seems like a great one to
me.

> > If it is more complicated or not does not matter - what matters is
> > what it is *percieved* as.
> 
> yup.
> 
> 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.

if avalon developers perceive it as more complicated, I can't guess what
users will think about it :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message