The subject is about a set of tags that describe the requirements a container has to fulfil for reliable and predictable component deployment. To achieve that we must either (a) provide a complete model, or (b) provide a model extension mechanism. One of the options described in the vote will only result in division and failure to achieve the objective. As such the vote calls for unification but presents a solution that will divide. Hopefully a majority of people will figure out that this vote is premature and that perhaps there are some important and unresolved issues to be addressed. If not, I guess its history repeating itself.
The problem is that the solution to these issues is not going to be easy. By CMM/RUP standards that means we should tackle it first. By XP standards, it means that we might want to take advantage of what we have already agreed to, make a release, and expand when we know what we want to do later.
I would like to fully address these issues, but I don't want to give the impression that the extensions are core supported Avalon tags until we have solved those issues.
That said, I would like to get a point release out there so that we can start integrating Avalon Meta into Fortress and Phoenix (superceding what is currently there).
We have some difficult issues ahead of us as we resolve how we want to handle things like management extensions, ad-hoc instrumentation, lifecycle extensions, etc. If we get the core stuff out there now, then people can start migrating the currently defined components/containers to use the proper meta tags and have something that we can play with in more than one container (i.e. Fortress and Merlin).
We need to be clear that the extension mechanisms while they are really cool, are still extensions. It lets people who are adventurous play first, thus allowing us to gain a better understanding of the problem space and adopt the viewpoints of others. By placing the extensions in the lifecycle namespace now, it allows early adopters to play around with it, knowing it is alpha, as we come up with the formal plan.
If we try to solve this now, we will essentially hold up development by a large number of people/projects that really can use the standard for the core tags. Not everyone is interested in the extensions yet. I want to leverage the existing momentum and help us move forward. Who is to say that the extension tags won't end up officially in the avalon namespace? They very well may, but by the time they get there, everyone will know how to use them and what they enable. THen again, what finally does get adopted may be very different.
While they are being experimented with, I believe it is important not to have them in the core avalon namespace. Otherwise we will end up with the equivalent of the Component interface in our avalon tags. Arguing to hold up a potential release and integration of the same tags library because we don't have everything specified, seems to imply that we are closer to a solution than we really are.
Can you at least agree to them being placed in an alternative namespace while we hash out the implications with the goal that something enabling extensions will be included in the avalon namespace when we are done? I would like to do a release RSN so that we can start integration. When we solve those hard problems, we can adopt the resolution. Does that sound fair?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
