On Sun, 1 Sep 2002 22:56, Stephen McConnell wrote: > 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.
As I said a few days ago - it wont. The ComponentInfo will only contain names to implementationKey of ServiceInfo. The ServiceInfo will then container all information related solely to service interface. ComponentInfo may indicate extra constraints (ie I need QOS=3) or implementation strategies (ie I am a QOS=3 implementation) but other than that the ServiceInfo will contain all the service specific stuff. -- Cheers, Peter Donald *------------------------------------------------* | Trying is the first step to failure. | | So never try, Lisa - Homer Jay Simpson | *------------------------------------------------* -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
