Stefano Mazzocchi wrote: [...]
From the comments on this and based on the discussions of the past months, I vote for this changed proposal:
I would like to see three containers, each one of them extending the one underneath.
- basic container
- embeddable container
- standalone container
the first should fit with the framework to provide a reasonable lightweight system for simple avalon uses (no fancy stuff like pooling or anything).
users of this basic implementation should be the people willing to learn avalon or use it in their own stuff but without fancy features.
the second should be the juicy implementation of the avalon framework, but should remain embeddable. Since it extends the basic framework, every change applied to the framework reflects up.
users of this implementation will be projects that use avalon extensively but internally (as an embedded COP system)
the third should be the biggest implementation, extending the second and providing standalone running capabilities.
users of this implementation will be projects that are run directly by avalon with full IoC.
Tweety can be the first
A mix of Merlin and Fortress can be the second
Phoenix can be the third
Note that this is more a community vision than a technical vision. All technical decisions will be made *after* this vote is taken.
So, do you like this vision? would you like it to happen?
**********************************************************************
This is more a community vision than a technical vision. All technical decisions will be made *after* this vote is taken.
**********************************************************************
We shall have one only container, that can be built to match the following profiles:
_micro_ container
_standard_ container
_enterprise_ container
The _micro_ implementation should fit with the framework to provide a reasonable lightweight system for simple avalon uses (no fancy stuff like pooling or anything)
The _standard_ implementation is the juicy implementation of the avalon framework, and should remain embeddable. It's to be used as the normal Avalon container. Users of this implementation will be projects that use avalon extensively but internally (as an embedded COP system), like Cocoon now.
The _enterprise_ third should be the biggest implementation, providing standalone running capabilities. Users of this implementation will be projects that are run directly by Avalon with full IoC.
Finally, there is a _tutorial_ container package (tweety&egg) that shows the Avalon patterns by implementing them one by one.
-oOo-
ATM, the containers we have now map like this:
_tutorial_ - Egg+Tweety
_micro_ - Tweety
_standard_ - Merlin and Fortress
_enterprise_ - Phoenix
Egg is already tutorial only, and Tweety can be taken apart into simpler parts and made into steps for comprehension.
Tweety as it stands can become the new "Default" stuff and supercede the default implementations we have in framework.
Merlin and Fortress are in the same domain and can be reduced to a single entity; they shall use the utilities created in the micro version, as they do now with Excalibur utilities that will go in micro.
Phoenix is highly pluggable, and it seems to be best to keep it the same from the outside: all the frontends remain the same and implement the core using the standard container.
So, do you like this vision? would you like it to happen?
--
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]>
