Stefan, I did think about this for a while. IMO reducing everything to services would make HiveMind simpler than we'd like it to be.
The basic problem I see is that a service's implementation (including configuration) is specified in a single module whereas a configuration's contributions can be scattered across all loaded modules. This scattering of contributions is definitely not something we'd want to give up. Thus, to unite the service and configuration concepts we'd also have to allow for a fragmented service configuration. I don't quite see what that would look like or how it would be an advantage... Cheers, --knut On Fri, 26 Nov 2004 04:02:28 -0800, Liebig, Stefan <[EMAIL PROTECTED]> wrote: > > I was thinking about making HiveMind simpler and more generic. > My thoughts went into the direction of "dropping" the configurations as > they are today. > Why not viewing configuration/contributions as services implementing > some data interface, i.e. generalizing services and configurations. > From a Pojos point of view there is no difference, it has constructor > parameters or setter parameter being of some interface. List is also > an interface of a component that could have been implemented by a > service. > Maybe it is possible to write a nice ServiceImplementationFactory > that does things like converting a contribution into a Map!? > > Just a few thoughts for the weekend to share with you! > > Stefan > > compeople AG > Untermainanlage 8 > 60329 Frankfurt > > fon: +49 (69) 272218 - 0 > fax: +49 (69) 272218 - 22 > email: [EMAIL PROTECTED] > home: www.compeople.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
