Stephen Haberman wrote:
> When you get to the documentation, could you include a small bit on why
> Turbine needs its own container? I trust that a new container is needed
> since you're implementing it, and I take it that it has to do with
> dynamic loadability, but I'm just curious.
As an Avalon committer and a long time Avalon user, even not having seen
what Jason has done, I'm sure that by creating a new container he did
the best thing. Oh, and also because Peter Royal is giving him a hand ;-)
I'm curious to see what Jason has done, since we're rearranging to have
more easy and clearly defined containers.
Seeing what Jason has done will give us a big hand, and I hope we can
someway integrate its concepts in Avalon.
> I'm semi-following the avalon-dev list and it's probably confusing me
> more than anything,
;-)
> but I get there are several containers (EMC,
> Phoenix, Fortress, and Merlin...now Tweety and MicroContainer?). It
> might be something the Avalon guys should write up, but a comparison of
> the different containers would be really
> awesome...features/pros/cons/future plans, etc.
Well, basically there was only one container implementation called ECM,
which came from the Cocoon world, and a server called Phoenix.
ECM was simple, it just loaded and served components, while Phoenix can
manage reusable components with dependencies called Blocks (that come in
.bar archives) and fill server apps made out of block assemblies (.sar
archives).
Now, we have in an advanced stage the successor to ECM, called Fortress.
What Jason is doing is to use Fortress someway and augmenting it with
what you need, as basically Cocoon does.
It's the best choice ATM.
What we are doing now at Avalon, is to make containers that will be able
to be augmented without subclassing, and have increasing functionality:
- tweety: very basic, used for learning purposes. It just instantiates
your components one after the other and then disposes them.
- microcontainer: the first "serious" container, to be used embedded in
your system. One container, one component, no dependency tracking, no
fancy resolving. Just use that component.
- Fortress(2): the final Fortress version, that can handle dependencies
of component from a common descriptor file.
- Phoenix: a server that can manage blocks and server apps.
All other names you hear will probably be merged in these containers.
- Cornerstone is not a container but a set of blocks, ie ready to use
services.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
