Leo Sutic wrote:
> Robert,
>
> I see three levels of increasingly more Magic in the container:
>
> Single-component container (MicroContainer):
> Use in environments where you want to use an Avalon component
> in a non-Avalon program. See my separate mail about this.
> Big thing: No external metainfo.
Take a look at tweety, it's a really basic basic basic container.
You define the components and it runs them in order. Simple as that.
> Embeddable Container (used to write blocks):
> For things like Cocoon. This is where Fortress etc. fits in.
> You have your metadata and so on, but the container is intended
> to be used inside something else - Tomcat, for example.
> Some external metainfo required.
>
> Stand alone container (used to assemble blocks):
> Phoenix. Loads of metainfo.
Hmmm...
It seems to make sense, but I still see too much overhead in having to
manage even only 3 containers.
We need only *one* motor, and that motor should be Fortress2 (with
Merlin included).
I still fail to see how Fortress would help "to write blocks".
Hmmm...
My basic requirement ATM is to have reusable components.
*One* component format.
*One* assembly specification.
I've seen projects try to use Avalin lifecycle stuff even at the lowers
level and not see real benefit. Making all my classes logenabled
wouldn't bring me benefits.
Size matters, and IMNSHO we should start on focusing on components that
are pluggable, reusable, etc...
Why not simply standardize on blocks and say component=block?
This would bring us to having a single component system, and the
possible difference *only* in the assembly; this said, a single assembly
mechanism isn't bad either.
--
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]>
