avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Sutic" <leo.su...@inspireinfrastructure.com>
Subject RE: Service and other Terminology
Date Sun, 01 Sep 2002 13:10:06 GMT


> From: Stephen McConnell [mailto:mcconnell@apache.org] 
> 
> Peter Donald wrote:
> > On Sun, 1 Sep 2002 02:04, Stephen McConnell wrote:
> > 
> >>>  <provides>
> >>>    <role>
> >>>      <key>conn-manager</key>
> >>>      <interface>org.apache.avalon.ConnManager</interface>
> >>>    </role>
> >>>  </provides>
> >>
> > ...
> > 
> >>    2. I don't feel comfortable with the <role/> element - roles
> >>       describe a form of usage of a artifact by a consumer - its
> >>       the consumer that understands a role, not the source of
> >>       the functionality - I would stick to <service/> as the
> >>       subject of what is provided.
> > 
> > 
> > The role is an equally valid concept from either end. The "Harrison 
> > Ford"
> > Component can declare that it will fit into role "Han 
> Solo". The "Fisher" 
> > Component can declare a dependency on "Han Solo" role via key 
> > "love-interest".
> 
> And in both cases it is neither Harison Ford or Carrie Fisher that 
> contain the role.  The role is defined outside of them - they 
> represent 
> components that are defined by something else and only "fit" 
> in terms of 
> the matching of their respective sevices and attributes with 
> the outside 
> thing. The outside thing in this example is a script.
> 
> I.e. a <provides/> context should not be containing 
> information about roles.

Agreed - but I think Peter is using the role here as a shorthand for
the interface name. In the example given, if my code requires a
org.apache.avalon.ConnManager, I can declare that I require a
"org.apache.avalon.ConnManager", or I can use the short form
"conn-manager".

I'd -1 that on the grounds that we'd need a canonical list of
short names, which is yet another thing to keep track of.

Then again I could be wrong and Peter means something else.

Peter?

/LS


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


Mime
View raw message