Peter:
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.
Stephen.
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 suggested
> 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 resources
> 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 that
> (but then again I think they will need time to mature anyways).
>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
