> From: Stephen McConnell [mailto:[EMAIL PROTECTED]]
>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
