avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Minimum Set of Tags (Revisited)
Date Tue, 08 Apr 2003 16:23:12 GMT


Stephen McConnell wrote:

>
>
> Berin Loritsch wrote:
>
>> This is not the time to decide what namespace (i.e. @avalon.*)
>> you think a tag should be, but what the actual name and attributes
>> should be (i.e. @*.name attr="foo").
>
>
>
> It is also the time to state with clarity the purpose of this 
> iniative.  My assumption is that we are working towards the defintion 
> of a set of tags that can be used independenly of any container to 
> provide the supplimentary meta info needed for any container to either 
> deply the component, or signal an inability to deploy.
>
>>
>> My understanding (after the discussions with Peter and Stephen are):
>>
>> @avalon.service type="fully.qualified.ClassName"
>> @x-avalon.lifestyle type="singleton"
>> @x-avalon.name my-component-name
>> @avalon.component
>> @avalon.role
>>
>>
>> Here are the concerns expressed (some already addressed):
>>
>> 1) We should use attributes instead of values (type="" value="") 
>
>
>
> Possible - don't have a problem with this.
>
>>
>> 2) Phoenix use of @avalon.service and Merlin use differ.  The
>>    semantics of the type name differ.
>>    * Version should not be encoded (Merlin), but specified seperately. 
>
>
>
> I disagree - but I'm willing to accomadate the change.
>
> :-)
>
>>
>> 3) Dislike of the @avalon.component/@avalon.role
>>    * Boils down to personal style 
>
>
>
> Disagree.
> I think this is more about content - not usage.
>
>>
>>    * Any component that implements a role interface supports that
>>      service (According to Framework 4.0 standards). 
>
>
>
> Disagree.
> This is a usage constraint that is implied by AF4. 


Correction -- This is a usage constraint that is NOT implied by AF4.

Steve.

>
>
>>
>>    * Whether that role interface is specified by @avalon.service
>>      or @avalon.role is irrelevant.
>
>
>
> Disagree.
> The notions are quite different.  One is declaration of an interface 
> as a work interface as distrinct for the potential to use the same 
> interface in other non-work related situation.  The other is an 
> explicit statement of the exposure of a service by a component.  
> Implementation of a service is not the only way a component can 
> deliver a service.  In Merlin land I have components the dliver 
> services but do implement the service interface.  You need to make 
> sure that assumptions you put into a tag do not imply implementation 
> decisions.
>
>> I prefer marking the
>>      role interface unless it is not available in the JAR,
>>      Stephen and Peter prefer marking the component implementation.
>
>
>
> The two are orthoginal.  If I under you correctly you want to make the 
> assumption that if an interface that has been marked as a role is 
> implemented by a component, then you can infur that the component 
> exposts that interface as work interface.  I disagree with this 
> assumption.
>
>>
>> One thing I would like to propose is a change to @avalon.component
>> which would do away with a need for @x-avalon.name:
>>
>> @avalon.component name="my-component-name" 
>
>
>
> You can enhance this to cover the component implementation version 
> declaration with the following:
>
> @avalon.component name="whatever" version="1.2.3"
>
>>
>>
>> Alternatively, if we want the "extension" semantic to make it
>> clear that the attribute is optional:
>>
>> @avalon.component x-name="my-component-name"
>
>
>
> What does "optional" mean. Does it mean that I can ignore it without 
> compromizing the componet?
>
>>
>> Thoughts?
>>
>> What am I missing? (Please don't say "I don't like x-*").
>
>
> Zutt!
>
> 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


Mime
View raw message