[Opensim-dev] RFC: Refactoring Scene.cs so that modules directly invoke services from CommsManager

[Justin Clark-Casey]

Teravus Ovares wrote:
> CommsManager was originally for the Inter-region communication.  It
> wrapped Grid Comms and single instance comms under one roof.
> 
> You're planning on expanding that definition to region services?
> 

Conceptually, it does seem to me that CommsManager provides services rather than comms as of such.  For example, if you 
want to get an asset you get the AssetCache (which perhaps should really be called AssetService) and invoke methods on 
that.  Whether that's really a pure in memory implementation, something that contacts a local filesystem (or database) 
or a service that makes the request over a network is neither here nor there.

So possibly CommsManager could be renamed ServicesManager.  This might make its use more intuitive from the point of 
view of future module writers (which is probably out most important constituency here).

Perhaps, though, one could go further and makes all the services sitting in CommsManager into region modules instead. 
This would unify 'services' and our existing 'modules' (which provide region services) into one interface.

However, I don't know whether this makes the connections between them (e.g. the fact that the user module relies on the 
inventory module to set up new inventories) less obvious.  I'm also not sure whether it is better to maintain a 
distinction between 'services' and 'modules', where services may potentially involve network communication.

> Best Regards
> 
> Teravus
> 
> On 12/18/08, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
>> Teravus Ovares wrote:
>>> You would think that the service wrappers would be something that
>>> should go into scenebase, the scene base class as virtual.   The idea
>>> behind this is, 1.  it would be out of Scene.cs.   2.  It would be
>>> available, if someone intends on deriving another Scene class from
>>> SceneBase.
>>>
>>> Then again.  Maybe Scene is too complicated and encapsulates too much
>>> specific functionality to make it reasonable to expect someone to
>>> derive a separate class from SceneBase.
>> Yeah.  I still am more in favor of switching everything to get services through CommsManager (which may be slightly
>> misnamed).  On a little further digging, a lot of modules do this already, so we now have this inconsistent situation
>> where some stuff is fetch through CommsManager and other things are done via CommsManager wrapping methods on Scene.
>>
>> It would be nice to be consistent in this.
>>
>> Also, going directly to CommsManager may make it easier to get services by interface in the future, instead of the
>> existing hardcoded fields (in the same manner as interfaces are registered on Scene itself).
>>
>>> Best Regards
>>>
>>> Teravus
>>>
>>> On 12/18/08, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
>>>> In Scene.cs there are quite a few wrapper methods that appears to exist primarily to relay calls from modules to other
>>>> services.  For instance, Scene.AddXmlRPCHandler() just recalls AddXmlRPCHandler() on the BaseHttpServer.  Some modules
>>>> make use of this method while others use Scene.CommsManager.HttpServer.AddXmlRPCHandler()
>>>>
>>>> I would like to refactor code such that services available through CommsManager are called directly rather than through
>>>> Scene wrappers.  Although this goes against the Law of Demeter (http://en.wikipedia.org/wiki/Law_of_Demeter) I think
>>>> that the advantage in reducing the large number of disparate methods on the Scene is worth it.  The alternative is that
>>>> the number of Scene wrapper methods continues to grow indefinitely as new service methods are introduced.
>>>>
>>>> Comments?
>>>>
>>>> --
>>>> justincc
>>>> Justin Clark-Casey
>>>> http://justincc.wordpress.com
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>> --
>> justincc
>> Justin Clark-Casey
>> http://justincc.wordpress.com
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com