Magnús Ţór Torfason wrote:
> 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.
I agree with all of the above! The patch to Configutations has already
been
aplied.
If you care to write the patch to the Services framework, I'd be happy
to commit it for you.
As a second step, the services that use Service.getProperties() method
should be eventualy converted to using Configurations.
Rafal
PS. Don't you find the Configurations class name a little unwieldy?
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
