avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [Proposal] AMTAGS continued
Date Sat, 26 Jul 2003 10:33:26 GMT

Berin Loritsch wrote:

> The more I think about it, the less I like Stage and Extension being 
> in the
> Avalon namespace.  I just have this nagging feeling that these tags 
> will be
> superceded in the future by something else.  Consider all the 
> evangelization
> that Peter D. did with interceptors.  I have dabbled with 
> interceptors, and
> they do open up a wide variety of different possibilities.  That said, 
> I am
> not ready to dump some code out there and have it start being used.
> Since the Avalon namespace should reflect stability, and the abilities 
> that
> the tags represent are not core to pure Avalon components, I really am
> having a hard time justifying their existence in the Avalon namespace.  

The notion of a lifecycle stage is core to Avalon at this level of 
abstraction. We are talking about a dependency that a component has 
during its deployment cycle.  We are not talking about how the 
dependency is resolved or applied.

> In the short term, they will work just fine.  

I think you mixing up concerns about excalibur-lifecycle with the 
separate aspect of the lifecycle stage dependency declaration.  These 
are two different things.

> However we have to consider the long term.

We certainly do.  In the longer terms I expect the concept of a 
lifecycle stage to remain as an intrinsic element of our component 
model.  I also anticipate that we will evolve different solution 
strategies to deal with these deployment dependencies.  One fundamental 
truth is that lifecycle stage dependencies will not disappear - what 
will change is how those dependencies will be handled.

Certainly new things will come along that we will want to experiment 
with, and after that experimentation we may want to consider other 
approaches - approaches that leverage the stage and extension tags.

> For that reason, I strongly recommend that we put these two tags in their
> own namespace.  

I strongly disagree with you recommendation. The notion of a stage is 
intrinsic to the component model.

> For the short term, we [could] modify all the containers to
> at least recognize the tags 

1. Tools recognize tags - containers recognize meta-info.

2. what you describing is actually container recognition of
   a particular dependency - in this case a stage dependency
   which is core to validation of a type

> and decide whether they can support the lifecycle
> extensions or not.

I mentioned in one of my earlier emails that we need to clarify our 
specification approach.  I don't think that the @avalon tags should be 
specified in terms of container constraint or obligations.  In effect 
the AMTAGS spec should be targeted to the tool builder.   Tools, such as 
a meta-info generator can create meta-info - its the meta-info 
specification that carries implications  relative to a container.

> The impact to Merlin is a tag name change, which is inconvenient but not
> such a high impact as to be a blocker.  

Consider it a blocker - because I think (a) your looking at this from an 
implementation point of view and (b), I think your looking at this from 
the wrong abstraction level (but I'm not sure) and (c), acceptance of 
your position would  inconsitent with the meta-info model and would be 
detrimental to overall meta-model work in which these notions are 
intrinsic first class aspects.

> As none of the other containers
> support the tags in the manner that Merlin does there is no impact on 
> them. 

What your really saying is that Merlin is the only container platform 
that provides support for explicitly declared stage dependencies.  
Without this notion, components using stages in Fortress will fail in an 
unpradictable manner in both Phoenix and Merlin. Lets get back to the 
purpose of AMTAGS.  It about declaring criteria such that (a) we use 
tags in a consitent manner enabling and forstering tool development, and 
(b) enabling and facilitating and common meta-info model through which 
we will able to achieve component portability across containers.

> After saying all that, I would like Fortress and Merlin to be on the same
> page for declaring and using the extensions (making them more 
> cross-container
> compatible).  The change would be made to Fortress--not Merlin.

Presumably Fortess will migrate to the meta-info model. Multiple 
examples exist in the avalon-sandbox/merlin repo - let me known if you 
need a hand.

> I propose that the tags currently named @avalon.stage and 
> @avalon.extention
> be placed in the "lifecycle" namespace making their names be 
> @lifecycle.stage
> and @lifecycle.extention.


The stage and extension tags reflect an abstract semantic that flows 
down through the complete meta-info model.  I cannot agree to your 
proposal because of the "thin-edge-of-wedge" factor.  Lifecycle stages 
are intrinsic elements of a Type definition.  A type definition is 
mirrored by component meta-data.  Component meta-data is managed as a 
component meta-model.  A meta-model is reflected in a deployment 
system.  Your recommendation would initiate a fragmentation of what is a 
complete, consistent and functional structure.

> By placing them in another namespace, we can keep the tags and the 
> abilities
> they represent without having to try and argue them in.  I tried to 
> like them
> in the Avalon namespace, but the more I tried the more uneasy it made me.

I am certainly happy to help you out with anything concerning the 
handling of extension and stage mapping.  In fact, if you careful about 
the approach to internal management you can abstract yourself from the 
lifecycle extension API. This shifts the focus of stage and extension to 
be concerns related to deployment and (as distinct from runtime) 
dependency management.

My guess is that this is probably where you and I are disagreeing. I 
view stage declarations as something more abstract than the lifecycle 
extension package - and something totally intrinsic to open component 
management.  What is fundamentally important is the Avalon component 
model has a distinction between runtime and deployment dependencies.  
The solution to meeting those dependencies remain a container concern.

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