Berin Loritsch wrote:
Stephen McConnell wrote:
<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.
Ohhh - no - not limbo - neither in nor out. This is worse - the purpose of type info is to declare what every container needs to know. And every container needs to know if a component uses lifecycle extensions or not. Moving the subject to x-avalon simply states that this point is unresolved - which is unnecessary and will only result in a semi-model that is only useful for some containers and not others. Immediate impact of that is that you have some containers that consider x-avalon as intrinsic and other that ignore its existence. None of this stuff can be ignored - that's the point.
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).
The optionality of an extension is a property of a named stage. The existence of a stage declares a requirement for the support of lifecycle extensions. There is not need a "uses" declaration because its already explicit.
I am just trying to separate concerns here.
I agree that the lifecycle extension semantics at the meta-info level is a potential condidate for expression as an meta-info-extension. However, I really think it is way too early to be playing around with this at this time (aka - yes, but).
Instead of attempting to define a real meta-info-extension model now, I think we should wait and gain experience. The result of taking that position means that we need to declare lifecycle extension features explicitly. BTW, I don't see a down side here because the lifecycle extention stuff is intrinsic to the component deployment model.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
