cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject RE: [RT] On building on stone
Date Wed, 24 Mar 2004 21:18:25 GMT
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.

Not that I'm against switching to another container, its just that I thought
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.

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. 

It seems pretty obvious though, that there are two contrasting issues here:
1. Cocoon's charter is not to be a container. Having an internal container
implementation violates this idea.
2. Cocoon is very vulnerable to container issues because it doesn't "own"
the code. Furthermore, a container may not exist that supports Cocoon's

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 other
options.  However, I would make sure that other available frameworks cannot
be leveraged to some degree before doing the whole thing from scratch, but
that is just me.


-----Original Message-----
From: Hamilton Verissimo de Oliveira (Engenharia - SPO)
Sent: Wednesday, March 24, 2004 12:44 PM
Subject: Re: [RT] On building on stone

-----Mensagem original-----
De: Bertrand Delacretaz []

> IMHO the current perception that Cocoon is a "big thing" is largely due 
> to the complexity imposed by Avalon, 

Sorry. Can't agree with that. 
Avalon was born from Cocoon codebase. What was imposed to Cocoon? Its should
be the opposite.

> and this will go away with a 
> simpler container framework. We'll just have to adjust our user's 
> perceptions once this is realized ;-)

Hey, wait a minute. You're about to create a container that will support
_hot deployable dynamic polimorphism_ and this will be simpler than ECM? I'd
like to see that.


View raw message