avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future)
Date Wed, 27 Nov 2002 10:18:37 GMT
(only replying because of the "[vote]" in the subject line; think this
has already been superseded by Berin's proposal)

there is too much technical detail in the below and too much references
to existing code for me to support this proposal. I like the "vision"
and general direction though.

So, I vote -0

cheers,

- Leo

On Tue, 2002-11-26 at 12:15, Nicola Ken Barozzi wrote:
>  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                   nicolaken@apache.org
>              - verba volant, scripta manent -
>     (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> 



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message