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

[Kyle Hamilton]

Be aware, I'm sick and on weirdness-inducing medications, so if I'm
completely out of line please be gentle?

If OpenSim is truly going to be a modular platform, it needs to be
designed like one, down to service-interface level.

CommsManager should have an entry for each type of proxy, and return
that when requested (very much akin to the LogManager).  It should be
a singleton.

Each proxy should be a singleton, and should have an entry (or a list
of entries, if the admin wants to use more than one source for any of
them) for where it's going to get its information, and if a proxy is
instantiated without a data source, it should throw an exception
on-load.  (I'm imagining a hybrid of UserServices that can be used for
authentication, including name/password, OpenID, and cryptographic
systems, with a priority for each -- and the same with AssetServices.
Since the UUID can be used as a global identifer why not use a
peer-to-peer asset location service a la DHT?  Keep a 'home' asset
server for where the user's local assets are stored, and cache remote
assets into the local AssetCache...)

Incidentally, is there any direct mapping between URLs and the service
remote method invocations?  If there is, it should be documented
somewhere.  If there isn't, should there be?  (Rather like Remoting
was supposed to work, but didn't between .net and mono?)

-Kyle H

On Fri, Dec 19, 2008 at 6:38 AM, Justin Clark-Casey
<jjustincc at googlemail.com> wrote:
> 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
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>