Berin, I see several ways to proceed. One way that seems to be floating around is to put existing code into sort of a maintenance mode until the new container(s) are ready to replace them, and to focus the community on the process of developing replacement(s). Another is to begin to build the common container framework, and use that common framework to morph the existing containers into the desired container(s), continually proving that the new framework works.
----------------- > we had identified as the #1 need for Avalon 5 > is better container/component contracts. :-) > for Avalon ME (Micro Edition) > I think the memory constraints rule [pooled and "factory" components] out. OK, can you clarify this? At first I thought that you were saying that pooling and factory pattern imply greater memory constraints, with which I disagree. But then I read the rest of your note, where you propose using "http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider";, and since that approach uses a factory to construct the concrete provider, you clearly are not discarding the factory pattern. So I feel that I am missing your real point. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
