hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Massimo Lusetti <>
Subject Re: Few interfaces with a lot of implementation
Date Wed, 18 May 2005 13:37:26 GMT
On 5/18/05, Knut Wannheden <> wrote:

> 1. If you at registry construction time already know which of the 40
> implementations is the "correct" one for a given service then you
> could actually encode this knowledge into the module descriptors, in
> which case you would end up with 10 services instead of 400 (of which
> 390 would be unused).
> 2. If you on the other hand have to be able to let client code at
> runtime chose which of th 40 implementations to use then you indeed
> have to create 40 distinct services. This is because a HiveMind
> service can at runtime only have one implementation.

I can decide which implementation to use only when data (with the
corresponding meta-data) comes in the application flow, i read it and
then I'm able to decide which implementation i need, so i think i
could go with 2.
> 3. If your service itself can at runtime decide (let's say based upon
> argument values passed to the invoked service method and environment
> settings) which of the 40 implementations to use then you have the
> possibility to create a "dispatch implementation". You'd again end up
> with a total of 10 services. In version 1.1 of hivemind-lib there is a
> service factory that helps here: hivemind.lib.StrategyFactory. See
> and

I've to investigate this more as it seems quite interesting, but one
question comes:
How this work if the first kind of data bits are for
service-a/implementation-a then the second kind of data bits are for
service-a/implementation-b, since this could happen very frequently?
Isn't true that i need to declare all the possible
services/implementation within every hivemodule.xml ?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message