My $.02 > This question is really at the heart of a lot of the recent > discussions. Traditionally, Avalon has been about the framework API. > Anything not in the framework has been up for grabs for the container > implementer. The great advantage to this approach is that we end up > with a lot of diversity and freedom to explore a number of different > solutions. This means we have specialized containers for various > scenarios. You get to use the right tool for the right job. >
If this only were true... I support the idea of different container implementations, but it doesn't seem to be working within the Avalon community because of the lax-ness of the Avalon Framework specification. > While this argument has merit, I believe it misses out on what Avalon > set out to deliver. I don't believe we intended on creating a > component oriented framework where reuse was a secondary > consideration. Seeking to rectify this situation seems (to me) > perfectly in line with our charter and mission. > Amen. > Niclas's Unifying Vision > > Basically, Niclas's big argument is that our components don't work > cross-container. As far as he is concerned, the framework is > incomplete because it allows for these sorts of discrepancies. He > would like to extend the framework to include a more complete set of > container-component contracts so that if you followed this > specification, your component would work in any true > Avalon-compliant container. This would require a TCK or two which > would help lay out these rules. I agree. Qualifications follow at the end of this email. > Stephen's Total Domination > > Stephen's proposal is actually not very different from Niclas's > vision. The differences (if any) perhaps rest mostly with what > should be included in the TCK. Stephen feels that there should be a > single component model design which would (in my eyes) be heavily > influenced by the Model Driven Architecture paradigm. I disagree. Qualifications follow at the end of this email. > > Berin's Zen Framework > As I understand, Berin's dream is not too different from Leo's (see below). > > > Leo's Container Aspects > > I'm still getting up to speed on this one, so Leo may need to step > in and clarify, but essentially, this approach is to build a new way > to assemble a container from multiple "aspects" or "facilities." > These container parts would be independent of one another as much as > possible and easily replaced or extended. > > The aspect approach certainly allows for multiple containers, but in > effect, they would all be various combinations of aspects, component > handlers, and facilities. If I understand correctly this would also > allow for more flexible framework constraints if one so desired -- > perhaps even "pluggable" framework specifications. In this way, > support could be added for the existing Avalon framework and > container nuances while leaving the option of alternative specs > open. I am 100% behind this idea. > Keeping the Existing Containers Approach > > Finally, another alternative is to simply maintain our current > course and offer support for Fortress, Phoenix, and Merlin. In this > case, we would definitely be supporting multiple containers, though > there is certainly interest in providing better cross-container > support. Of course, it is somewhat difficult to see exactly how to > do that without resorting to an approach similar to ones listed > above. > My introduction to Avalon was not an easy one, mostly for this very reason. I am for multiple container implementations. But I would rather see them on sourceforge.net or java.net than on avalon.apache.org. It is confusing for the Avalon community to be working on (and attempting to support) a half-dozen containers at a time. One reference implementation (with pluggability) to rule them all! > > 1. Why do I use Avalon? I don't :) But I would like to. Currently, I am more of a PicoContainer person. But Avalon has the Apache branding :) Don't underestimate how important this is. Also, Avalon has a certain nostalgic value in the COP world. On top of that, I really do believe that the best minds in COP are the most active on this list. That is primarily why I am subscribed to this group. There are a lot of great ideas floating around here. I think that Avalon could either have a bright and sunny future, or it could crash and burn before years end. > 2. What do I feel Avalon's mission to be? I feel that Avalon's mission is an idea (or collection of ideas). And Merlin's vision should be to realize those ideas. I understand the vagueness of this statement, but Avalon itself is vague. It is a place beyond the mist :) That is why there needs to be a concrete representation of Avalon (aka Merlin). > 3. Where do I see Avalon by the end of 2004? Either revolutionizing COP or an interesting history lesson. The jury is still out. > 4. How do I feel about Avalon as an umbrella project vs. a single > product? Avalon should be an umbrella for various and diverse specifications. Merlin should be an umbrella for various and diverse implementations. > 5. Should there be a formal framework specification? Yes. > 6. If so, what should it consist of? The current framework API nailed down. Meta-data should NOT be included in the specification, BUT a meta-data specification should exist under the Merlin hood. To sum up, I believe that "Avalon" should be known as a family of specifications. NOT "One specification to rule the all," but many specifications with versions and test cases. Specifications will have flaws. They will need to be updated/amended/discarded, but as long as they have test-cases and reasonable versioning, compatibility can be within an implementers grasp. I do not think that Avalon should include a single Model Driven Architecture that all container implementations must follow, however. We just aren't there yet. Regarding Merlin, I share Leo Sutic's dream of an extensible container. I agree with Niclas that there can be no "one size fits all" container; however, I think that the equivalent can be accomplished using a single container and a plethora of plugins (SoC). Thanks for your time! Jonathan Hawkes --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
