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 
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:mcconnell@apache.org
http://www.osm.net

Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin




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


Mime
View raw message