XAMTAGS

[Berin Loritsch <bl...@apache.org>]

Without all the long language of Leo's AMTAGS proposal, I would
like to build on the assumptions there, and introduce extension
tags.

Extension tags are tags that are PROPOSED for the avalon namespace,
however they have not been ACCEPTED yet.  This allows early adopting
containers to use the information supplied by these tags and provide
real feedback on how they would work.

So far, we have 2-3 tags that are proposed:

@x-avalon.role
     Marks a Service that is always to be exported.  This works for
     many solutions, but not all--this would be in addition to the
     @avalon.service, but would in no way replace it.

@x-avalon.info name="configName" lifestyle="singleton"
     Marks a component with a configuration name, and its intended
     lifestyle.  Containers that do not support a given lifestyle
     name would reject this component.  Currently, the list of
     lifestyle names are:
       - singleton
       - thread
       - pooled
       - transient

Alternative to the above lifestyle property of the info tag is this:

@x-avalon.lifestyle type="singleton"
     See above for description of lifestyle values.

The major difference between the combined x-avalon.info and the
separated one is that containers that do not want to support all
of x-avalon.info can still validate x-avalon.lifestyle.  I would
propose that it is strictly an either/or choice, we should only
allow the specification of lifestyle in one location.

What are your thoughts?


-- 
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock


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

Re: XAMTAGS

[Peter Donald <pe...@realityforge.org>]

On Fri, 11 Apr 2003 03:13, Berin Loritsch wrote:
> @x-avalon.role
>      Marks a Service that is always to be exported.  This works for
>      many solutions, but not all--this would be in addition to the
>      @avalon.service, but would in no way replace it.
>
> @x-avalon.info name="configName" lifestyle="singleton"
>      Marks a component with a configuration name, and its intended
>      lifestyle.  Containers that do not support a given lifestyle
>      name would reject this component.  Currently, the list of
>      lifestyle names are:
>        - singleton
>        - thread
>        - pooled
>        - transient
...
> What are your thoughts?

that it would do users more good to see them use the @fortress prefix. It is 
unlikely that they will be adopted by core given that they are not 
X-container so they will forever remain in x-avalon which does not seem worth 
it.

-- 
Cheers,

Peter Donald
He strains to hear a whisper who refuses to hear a shout.


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

Re: XAMTAGS

[Leo Simons <le...@apache.org>]

Stephen McConnell wrote:
> Berin Loritsch wrote:
>>
>> Extension tags are tags that are PROPOSED for the avalon namespace,
>> however they have not been ACCEPTED yet.  This allows early adopting
>> containers to use the information supplied by these tags and provide
>> real feedback on how they would work.

workable :D

>> So far, we have 2-3 tags that are proposed:
>>
>> @x-avalon.role
>>     Marks a Service that is always to be exported.  This works for
>>     many solutions, but not all--this would be in addition to the
>>     @avalon.service, but would in no way replace it. 
> 
> @x-avalon.role worries me a lot.
<snip/>
>  Bottom line - I think it come back and bite us.

same here, but I said that already, and I think it is okay to experiment 
with it, and I think it's also okay to experiment in '@x-avalon' 
namespace. I don't care so much whether its '@x-avalon' or '@fortress'. 
The important part is that people will recognize that '@<blah>.role' is 
experimental/proposed, while '@avalon.<blah>' is not.

> Concerning the remaining tag/tags - Fortress needs a name tag, Merlin 
> needs a name tag, Fortress needs a lifestyle tag, Merlin needs a 
> lifestyle tag. So a solution is already available - you could apply the 
> same model that Merlin is using @avalon.meta.name and 
> @avalon.meta.lifestyle.

uhm, part of the AMTAGS proposal is sort-of that Merlin should change to 
use @merlin.meta.name or something similar (really anything but 
@avalon). The idea is to have '@avalon' be a relatively common ground. I 
don't really want '@avalon.meta.<blah>' in fortress.

cheers!

- Leo



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

Re: XAMTAGS

[Berin Loritsch <bl...@apache.org>]

Stephen McConnell wrote:
> 
> 
> Berin Loritsch wrote:
> 
>> Without all the long language of Leo's AMTAGS proposal, I would
>> like to build on the assumptions there, and introduce extension
>> tags.
>>
>> Extension tags are tags that are PROPOSED for the avalon namespace,
>> however they have not been ACCEPTED yet.  This allows early adopting
>> containers to use the information supplied by these tags and provide
>> real feedback on how they would work.
>>
>> So far, we have 2-3 tags that are proposed:
>>
>> @x-avalon.role
>>     Marks a Service that is always to be exported.  This works for
>>     many solutions, but not all--this would be in addition to the
>>     @avalon.service, but would in no way replace it. 
> 
> 
> 
> Berin:
> 
> @x-avalon.role worries me a lot.  From what I understand of the intended 
> semantics, a component that implements this interface is *required* to 
> export this interface.  I.e. an @x-avalon.role occuring in an interface 
> implementated by a component is to be considered semantically equivalent 
> to an @avalon.service type="<interface-classname>" on the implemeting 
> component.  This bothers me because it means that I need to handle this 
> as a special case that is specific to a particular application 
> scenario.  My own experience with component based desktop applications 
> is not the same and have a real uneasiness about this tag.  Bottom line 
> - I think it come back and bite us.  If you really want to go ahead with 
> it I would follow Pete's suggestion and declare it under @fortress (or 
> an equivalent @avalon.fortress....).

I am changing my position on x-avalon.role--but not based on your
arguments.  As long as the tool is working within the same JAR, it is
easy to tool.  However if you expect that contract to be applied outside
the JAR and propogate to other JARs, then things become sticky.  It is
unclear how to make that work properly.

It is for that reason that I am changing my position.  The
@avalon.service works in all cases, so all should be weel.


> Concerning the remaining tag/tags - Fortress needs a name tag, Merlin 
> needs a name tag, Fortress needs a lifestyle tag, Merlin needs a 
> lifestyle tag. So a solution is already available - you could apply the 
> same model that Merlin is using @avalon.meta.name and 
> @avalon.meta.lifestyle.
> 
> This would ensure commonality between Fortress and Merlin.
> Cheers, Steve.

However, I am pushing toward community adoption.  The @avalon.meta tags
haven't gone through that.



-- 
"You know the world is going crazy when the best
rapper is a white guy, the best golfer is a black guy,
The Swiss hold the America's Cup, France is
accusing the US of arrogance, and Germany doesn't want
to go to war. And the 3 most powerful men in America
are named 'Bush', 'Dick', and 'Colon' (sic)".

-----Chris Rock


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

Re: XAMTAGS

[Stephen McConnell <mc...@apache.org>]

Berin Loritsch wrote:

> Without all the long language of Leo's AMTAGS proposal, I would
> like to build on the assumptions there, and introduce extension
> tags.
>
> Extension tags are tags that are PROPOSED for the avalon namespace,
> however they have not been ACCEPTED yet.  This allows early adopting
> containers to use the information supplied by these tags and provide
> real feedback on how they would work.
>
> So far, we have 2-3 tags that are proposed:
>
> @x-avalon.role
>     Marks a Service that is always to be exported.  This works for
>     many solutions, but not all--this would be in addition to the
>     @avalon.service, but would in no way replace it. 


Berin:

@x-avalon.role worries me a lot.  From what I understand of the intended 
semantics, a component that implements this interface is *required* to 
export this interface.  I.e. an @x-avalon.role occuring in an interface 
implementated by a component is to be considered semantically equivalent 
to an @avalon.service type="<interface-classname>" on the implemeting 
component.  This bothers me because it means that I need to handle this 
as a special case that is specific to a particular application 
scenario.  My own experience with component based desktop applications 
is not the same and have a real uneasiness about this tag.  Bottom line 
- I think it come back and bite us.  If you really want to go ahead with 
it I would follow Pete's suggestion and declare it under @fortress (or 
an equivalent @avalon.fortress....).

Concerning the remaining tag/tags - Fortress needs a name tag, Merlin 
needs a name tag, Fortress needs a lifestyle tag, Merlin needs a 
lifestyle tag. So a solution is already available - you could apply the 
same model that Merlin is using @avalon.meta.name and 
@avalon.meta.lifestyle.

This would ensure commonality between Fortress and Merlin. 

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net

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