avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: @avalon
Date Sat, 22 Mar 2003 17:33:39 GMT


Having gone over the lifestyle architectural model several time, I
completely agree with you that there are multiple viewpoints that can be
applied from a pure computation level.  However, in practice this is not
needed.  The four lifestyle are representation of something like 98% of
actual cases, and furthermore, they do not exclude custom lifestyle
handlers (at least in the case of Fortress and Merlin).  This represents
a compromise between architectural purity as opposed to the pragmatic
approach of keeping things simple and understandable).

With respect to the meta-data versus meta-info argument you are raising.
   IMO the lifestyle tag it is meta-info, communicating to a container
that the *type* of component requires a particular level of attention
with respect to the way lifestyle semantics are handled.  This is not
metadata.  In the Phoenix platform there is no notion of a lifestyle
simply because Phoenix assumes a singleton lifestyle policy. As we move
towards greater portability of components, Phoenix has to be able to
recognize components that it cannot handle.  The lifestyle tag is one of
the criteria expressed by a type that ensures this.

More generally, I think there are more important things to address here.
   Clearly the declaration of common tags is a first step towards
achieving consistency in the specification of meta-info criteria.  I
would argue that the process would be more constructive if we made the
assumption that a certain set of tags exist - and from that assumption,
work on ensuing that the respective interpretation of those tags by
different tools and resulting meta-info are consistent.


Peter Donald wrote:
 > On Fri, 21 Mar 2003 01:21, Berin Loritsch wrote:
 >>The only thing holding up consensus is you.
 > Same with the marker interfaces we have or will be deprecating. Same 
with the
 > compatability stuff that is in framework.
 >>So what would it take to
 >>change your mind?
 >>I am asking for three standard names:
 >>@avalon.component (in phoenix already)
 >>@avalon.service   (in phoenix already)
 > this is used differently in phoenix from the way you proposed. I 
 > that @avalon.role may be a better marker tag.
 >>@avalon.lifestyle (proposed)
 >>I don't recall us comming to consensus on avalon.component and
 >>avalon.service and yet you chose to use the avalon namespace.
 > Lazy consensus. If you have a problem with them then state it.
 >>So I want to add one more standard name, what's the problem from
 >>your viewpoint?
 > I think that the avalon namespace should be restricted to defining 
 > that the component requires or provides. lifestyle is not one of those
 > things.
 > Even if it was I don't think it is mature enough to be supported for 
all time.
 > Besides not being able to represent all of the potential lifestyles 
such as
 > "pooled during times X and y, transient other times" or "passivate under
 > condition X"
 > Hell - I don't even think the lifecycle concept is something we 
should be
 > marking up. I have described quite a few times in the past of a 
method via
 > which lifestyle could be broken down into atomic bits of metadata
 > ie
 > lifecycle=single-thread       := ( sharable=true,  multiclient=true  )
 > lifecycle=factory/transient   := ( sharable=false, multiclient=false )
 > lifecycle=poolable            := ( sharable=false, multiclient=true )
 > etc.
 > Then the container can read the metadata about the component and 
determine how
 > it will be handled. ie A component that is "poolable" can also be 
treated as
 > "transient/factory" if the container wants without effecting the 
client code
 > or component code. It effectively becomes a configuration decision and
 > tunable by the container. Even better it is future compatible.
 > Anyways if you want to try an develope a set of those then we can try 
 > (but then again I think they will need time to mature anyways).

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

View raw message