avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [AMTAGS] Updating the spec
Date Tue, 22 Jul 2003 19:41:33 GMT

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 

> 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

Sent via James running under Merlin as an NT service.

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message