<snip type="description of generic meta info"/>
And now for the contradiction - I don't think we should do this. As I described to Vinay - I think we should hold off until we get more experience with the basic meta-info model.
Thoughts?
What about using something more generic like Commons Attributes or something like that, and then using that library to interface with the Avalon meta info builders? From what I understand, Commons Attributes allows you to plug and play with the actual serialization format. It also is generic enough so that we don't have to write or maintain new tools--that project will, as well as providing a decent interface for us to provide everything we need in Avalon land.
I agree that *we* shouldn't be in the business of maintaining a generic attribute interface, esp. when there are one or more to choose from.
Also, as to the inclusion of the lifecycle extensions in the avalon namespace, the argument could go either way. To me it feels wrong, but not strongly enough to argue about it. Perhaps as a comprimise we can place them in the "x-avalon" namespace until we come up with a good way of being able to detect if a component requires certain container extensions.
One possibility to the container extensions issue is to have a special attribute to declare the significant namespaces for a component. Something like this:
@avalon.uses namespace="lifecycle" optional="false"
Which would mean that the container will have to know what to do with these entries, because they are significant. The "optional" attribute there will signify if the component can opperate normally without support for that extension (e.g. like instrumentation).
I am just trying to separate concerns here.
--
"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]
