I think it is rather clear that we agree on what to do with the three core Avalon tags: @avalon.component, @avalon.service, and @avalon.dependency. All of these are central to Avalon, and already have equivalents in AMTAGS. We just need to update the proposal text.
It becomes less clear when we talk about the rest of the different tags.
The particularly troubling challenge is how to mark attributes for the services, components, and dependencies. We could argue that tag attributes are always treated as service/component/dependency attributes. The builder would just happen to use the reserved attribute names directly in the meta.info classes. Another plausible idea is to namespace unknown attributes as attribute:foo where foo is the attribute name. This does incur the cost of additional typing, and while the purpose is clear we can run out of horizontal space rather quickly.
We need to think in terms of extensibility, and making certain things that are not central or core to Avalon in a separate namespace. By central and core, I am refering what is required to make *pure* Avalon components function properly. An extension would include technologies like Lifecycle Extensions. At least this is my line of thought. Another line of thought is that the lifecycle extensions are central (though not necessarily core), so they should be placed in the Avalon namespace.
That is well and good, but what about management extensions? What about remoting? What about all these other aspects that our Containers can add to the management mix? They need to be accounted for somehow. Without a sensible way of gathering arbitrary attributes, from any method, and applied to the proper information, none of these things would be truly possible. I believe that this is our biggest challenge.
The @avalon.context.* or @avalon.logger.* is not central, but it is core. It is useful information for validation and tooling. I can understand provision being made for them in the Avalon namespace.
I would like to make two main points:
1) I believe that the Avalon namespace should be reserved exclusively for CORE information. Tags that are central MUST be included, and tags that are not central MAY be included.
2) We need to limit our discussion based on source code, not the generated end product. I could care less about the XML markup. I am interested in how I provide the information in my source code, and how it affects the component.
The two points are from my view, but I think it will help us focus our attention on the important stuff.
--
"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]
