Committers, if this accepted, could you still leave different "toolkits" for
building customized containers available ? The point is that no matter how
many different containers Avalon would offer, there be always a project for
which no suitable container would be found. Either they may offer too much
or too little. Personally, would prefer to have several "toolkits" for
building the majority of possible containers + a few containers as examples
of constructing containers from those "toolkits"...
I remember that when first time I wrapped my business components into
Avalon lifecycle interfaces I wanted to see them running ASAP, but tweety
did not provide the ordering of components initialization and others
containers seemed too complex for start, so I had to come with a tweety
modification by myself ...
Stefano Mazzocchi wrote:
[...]
>
> 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?
From the comments on this and based on the discussions of the past
months, I vote for this changed proposal:
**********************************************************************
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]>
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
