You solution is pretty much what I've always envisioned....
The problem isn't the indirection ... its the *selection*.
Putting any specific solution into the framework creates a kind of lock that will be hard to break
in the future. Providing a reasonably flexible solution in the standard library or (the forthcoming)
contributions library is a better approach ... the less in the core framework, the better. The
HiveMind framework is supposed to be the bare minimum needed to construct more elaborate solutions
... the more that's in the framework itself, the more locked into a specific solution we become, and
that's a trap to avoid!
I regard switching of services as a very important feature which shouldn't
be completely moved to the contributions library. I fear that without direct
support in the core, it could be very expensive to setup in terms of
needed configurations, factories etc.
So I would suggest that the core libary at least "acknowledges" that there
is the need to switch between different implementations, but the selection
mechanism is left to the user.
For example we could allow the definition of multiple implementations of
a service :
<service-point id="Simple" interface="hivemind.test.services.SimpleService">
</service-point>
<implementation service-id="Simple" id="impl1" >
<create-instance class="hivemind.test.services.impl.SimpleServiceImpl1"/>
</implementation>
<implementation service-id="Simple" id="impl2" >
<create-instance class="hivemind.test.services.impl.SimpleServiceImpl2"/>
</implementation>
The first time this service is used, a special service broker (you already mentioned
this one in a previous mail) is used for selecting the right implementation.
The default (core) implementation of the broker could just raise an exception, or
select the first implementation found. This is the current behaviour in this case.
If there is a well defined interface for changing the implementation of the
service broker itself, the user could choose from different selection strategies
that are available in the contribution library. Properties, configuration or environment variable, choose whatever you want and configure it at a central location for all
of your services.
This solution is not too specific but eases things a lot.
Achim Huegen
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
