avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neeme Praks <ne...@apache.org>
Subject Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future)
Date Tue, 26 Nov 2002 13:46:02 GMT

(huh... finally I managed to catch up with all the recent threads about 
reorg) as an inactive committer, here is my contribution:
+1

(and I hope to find the time to help you guys out in implementing this 
proposal)

Nicola Ken Barozzi ::

>
> 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?
>


--
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