avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: urban legend ...
Date Wed, 06 Aug 2003 13:37:55 GMT
Berin wrote;
> The NanoKernel approach (smaller than MicroKernel) would let us add in
> exactly what we needed.  Features could be added in like
> components/modules.  The default set would be your ultra-lightwieght
> container.  Your super-phoenix would be made possible as well.  In fact
> new features we haven't thought of yet could all be made part of the
> container without forcing us all to agree to one set of requirements.
> That is my vision of the "one" container.  It isn't one-size-fits-all in
> the clothing sense of the term (i.e. one predefined hat for all heads).

Well, I think the J2ME dream, that I have is in vain, since almost no
developer ever has a J2ME installation on their machine.

You are basically proposing a container-container, which allows for
"features", such as "Avalon4 LifeCycle", "Avalon4 Configuration",
"Meta-Info model", "Phoenix Contexts", "Fortress Pooling", "Merlin
LifeCycle Extension", "PicoContainer IoC" and "Niclas Discovery" to be

Let's say that this is feasible and at all possible. Then we have a
technical roadmap, let evolution do the rest.

Such solution would lead to a multi-tiered system;

0. Avalon Framework.
1. Container-container. (1!)
2. Container extensions. (Some)
3. Pre-packaged/pre-configured containers. (Some)
4. Components. (A lot)
5. Tools. (Some)

Is there enough support behind such elaborate idea?

Is it possible to make some "compromises" on the current state of affairs
to get better support behind such an undertaking?

Although I think this is a difficult path to take, compared to "many
container"-approach, I will support it (even if that doesn't count).


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

View raw message