avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <leosim...@apache.org>
Subject Re: [proposal] AMTAGS (avalon meta tags)
Date Thu, 10 Apr 2003 09:53:03 GMT
Berin Loritsch wrote:
> Leo Simons wrote:
>> Leo Simons wrote:
>>
>>>  * @avalon.service
>>>  *   name="com.leosimons.my.MyService2"
>>>  */
> 
> I see this as
> 
> @avalon.service type="MyService1"
> 
> As is already set up and documented in Phoenix.  I like that, and would
> adopt that.

me too, and that's what I wrote down :D

my idea is that you must specify a ROLE, and that a container should 
always accept a resolvable FQCN pointing to an interface as a valid 
ROLE, and it may additionally support RCN (a classname which is 
resolvable within the context of the current file), or some 
container-specific value (like a ROLE stored in a registry mapping to a 
FQCN), as long as that value can be agreed upon between component and 
container as being a valid unambiguous ROLE. We already have a contract 
for ROLE, lets incorporate by reference :D

>>>  * @avalon.dependency
> 
> This is only for use in VALIDATING containers.

acked.

>>> extensible
>>> ----------
> 
> -1  Don't add ANYTHING until it is needed.

acked.

> I would like to add (either in the
> x-avalon namespace or the avalon namespace):
> 
> @avalon.role
>       Marks an interface as one that is designed to ALWAYS be exported.
>       I find it useful for 90% of all cases, and @avalon.service as
>       necessary for the remainder.

Bad idea. I may want to implement a work interface you wrote, but not 
export it. Implementors need the ability to "override" this kind of 
thing. It is okay to mark an interface as designed as a "work interface" 
in avalon scope, but making all classes which implement it export it 
"automatically" is _not_ a good idea and I know of at least one 
phoenix-based app it would totally break.

I understand the usecase (less typing!), but it will just cause too many 
hassles with existing apps.

> @avalon.component
>       Marks a class as a component--if we do not use this, then we
>       must agree on minimal way to flag a class as a component.

AIUI, a component is a class which provides a service. Providing a 
service is done by exporting a work interface. A component is thus 
marked as a component by the use of the @avalon.service tag. If you mark 
a component as a component without providing '@avalon.service' to mark 
its work interface, there's nothing you can do with the component. So 
this becomes redundant as soon as you drop '@avalon.role'.

> @x-avalon.info

I would prefer to make this part of a seperate proposal, ie XAMTAGS, 
basically because I haven't seen any satisfactory commentary on Peter's 
reference to the different kind of breakdown of the lifestyle as has 
been proposed in the past. I happen to think a different kind of 
breakdown makes sense :D

cheers!

- Leo



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


Mime
View raw message