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. Berin, 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 installed. 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). Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
