cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hamilton Verissimo de Oliveira (Engenharia - SPO)" <>
Subject Re: [RT] On building on stone
Date Wed, 24 Mar 2004 21:37:38 GMT
-----Mensagem original-----
De: Ralph Goers []

> It is interesting to see the discussion on "Avalon".  Avalon itself is
> actually pretty small. However, when you add on Excalibur it becomes much
> larger. I'm never clear when the discussion is about Avalon whether the
> discussion is really about Avalon or Avalon + Excalibur.

I think you are misunderstanding things.. Exacalibur is a set of reusable
components. Yup, there is also an ECM fella that shares the name and is used
by cocoon. But this doesn't make avalon larger.

> Not that I'm against switching to another container, its just that I
> Avalon was originally born from Cocoon in the first place.  What is ironic
> is things like the Source Resolver that used to be cocoon classes are now
> Excalibur classes.

Just for creating a library - or something similar - of reusable components.

> I think a major problem is that the "container" (i.e. Excalibur) has just
> gotten way too large.  IMO it should be about managing the lifecycle and
> pooling of components and nothing else. 

AFAIK ECM does exactly that and nothing else.. 

> Personally, I think the path that has been proposed is probably as good as
> any other. Sure, it will have negative consequences, but so do all the
> options.  However, I would make sure that other available frameworks
> be leveraged to some degree before doing the whole thing from scratch, but
> that is just me.


We have a different container implementation in every single corner
nowadays. I understand why is too risk for Cocoon to choose one of them -
social implications at most - and I agree. Under this conditions I think
Cocoon should have its own container implementation. 


View raw message