> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>
> 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.
Yes, but you still have a config file to put up with.
MicroContainer doesn't even need that. Get your component jar file,
you create your instance and you are go. Much simpler than
Tweety.
See my post "Think Small" for a walkthrough of MicroContainer.
> 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).
Then you are ignoring the reality which is that the motor that fits
one environment does not fit all environments.
Fortress may be the engine powering all our metainfo-enabled,
Magic-Laden containers, but if a prospective user will, I think,
want some *extremely* simple way of getting this Avalon
component she/he thinks would be *so* useful to work *fast*.
"Oh, you mean I have to download a Fortress? And write an assembly
descriptor? What is XML? But I just want to use this ConnectionManager.
I don't want to build some Castle or WTF it was called."
To give you an idea of my vision for Avalon's three containers,
here's what I think of them as, and the image I have in my head
of them:
Avalon/Micro: MicroContainer
Avalon/Embedded: Fortress
Avalon/Server: Phoenix, using Fortress.
As we go from Micro->Server, the coupling becomes looser and flexibility
increases. More Pure Fucking Magic, as Berin put it. Going from Server->
Micro, there's *less* and *less* committment to Avalon architecture.
MicroContainer allows you to use Avalon components almost like regular
Java classes. Of course, this means less magic as well, but the purpose
is this:
1) Include MicroContainer in framework.jar
2) Distribute framework, and some really useful components.
3) Show user how to use MicroContainer to use those components
in his/her own code. Please, Nicola, read my mail about
"thinking small". That is what I want the user to see
at this stage.
4) Soon, the user will want XML config, pooling and all that
Magic. Point to Embedded or Server, depending on the use
case.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
