>
> Yes, it would, but in reality, your patch should be to the Services API to
> get it to return what you want.
>
> thanks,
>
> -jon
>
I am using Configurations for other stuff than services :)
What you are talking about must be to modify the services api so that it can
return a Configurations. That is very attractive for me, but not the same
thing.
Two points:
1) The Configurations class can be used even if one does not have access to
TurbineServices. TurbineServices can however never return a Configurations
object unless it has access to it. Hence, the patch is more general when
implemented inside the Configurations class.
2) By implementing the function inside the Configurations one has access to
the underlying private objects, and can therefore copy it instead of
constructing it again. This is the easiest place to implement it,
regardless of where one wants to use it.
3) Note that my patch can be used recursively. One could get the
configurations for an RPC service, then get the configurations for each
handler of that service, each handler could then get configurations for each
functionality it offers.
If you -1 it I shall hold my peace and not mention it again. If you are
hesitating because you feel there should be a
TurbineServces.getConfigurations(serviceName) function, I can tell you that
this functionality would INCREASE the benefits of such a function, not
lessen them.
Magnus
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
