Multiple containers are not only helpful, but they are absolutely necessary. We will never be able to converge on the most generic and useable container specifications when there is only one to choose from. Using different approaches that all work with the same components helps us to determine important criteria such as:
1) Is the component *truly* supported accross containers? I.e. with the same meta data specified the same way, will the component function? 2) Which core feature-set is *critical*? I.e. not all features for components are necessary in all situations. Which features can be ignored with the component still able to function as expected? The list of critical and _nice_ features help to determine what belongs in Framework. The current Framework is definitely critical. The "Instrumentable" interface is most definitely a nicety, but it does not affect the component's ability to function. 3) What is the best way to perform a function? Using the example of our pooling code, we had at one point three different pooling mechanisms. The best points from all three mechanisms were merged into one unified approach. If it goes in Framework, the interfaces must be correct, and any implementations need to be the best. Having multiple containers is not only workable, but they are critical to the process of finding out what needs to be in framework and what is container specific. It will also help address the issue of how to handle things such as component extensions in a cross platform way, and how to make the component still work if extensions are not used. Considering that Stephen and I (primary developers on the two competing containers in Excalibur) have proven that we are able to work with each other, I don't think we will run into any serious or unresolvable problems. I believe that using metadata is the way to go, but I am not convinced that either Meta or Info are the best way to express it. If we can come up with one specification for how the meta information is *stored*, we can have multiple implementations like Meta and Info that make reading the metainfo easier. I would propose working with the Jakarta Commons Clazz project to help implement class/method attributes. That would provide the best way to ensure a generic solution that is used and maintained by more than just Avalon. I think that is the best solution as it raises the synergy with Jakarta (whom we just left) and with each other. If a third party is maintaining that critical piece of code, then there is no chance of personality conflicts here. Furthermore, we are not the primary on that project so that it forces us to be on our best behavior (esp. if we want commit privs for that project). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
