[Opensim-dev] Comms Manager

[MW]

A couple of issues/questions are:

How would a
Region/ServiceModule say what interface it wanted to register, it might
implement a couple but only want to register one, or it might want to
register its class type.

And I'm taking it we would still have
the ApplicationPlugin that could register with what regions it wanted,
so would still need the Scene.RegisterModule<>() interface for
them.


--- On Thu, 26/2/09, Justin Clark-Casey <jjustincc at googlemail.com> wrote:
From: Justin Clark-Casey <jjustincc at googlemail.com>
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev at lists.berlios.de
Date: Thursday, 26 February, 2009, 7:07 PM

MW wrote:
> I'm not actually bothered about the interface per se. What I require
is 
> to be able to dynamically load generic modules that no where in that 
> module does it know about IScene/Scene.
> 
> I actually see your approach as complex because it demands they need to 
> know how to register to a scene themselves when these types shouldn't 
> need to know. The types of modules I mean are ones where they just want 
> to register with the Core/Application and be accessed from anywhere in 
> the application.
> 
> Of course this module type doesn't fit all needs, but thats what
I'm 
> saying its not right to try to find a single solution that fits all 
> needs and turns out to be more complex than some modules require. And we 
> shouldn't rule out such generic modules.
> 
> Now we could still do meet the above requirement with you system, but it 
> would mean doing some automagic in a ApplicationPlugin (or whatever 
> interface they used) loader.
> 
> As the loader would have to provide its own IServiceCore implementation, 
> that it passed to the IServiceModules that it loaded, then it would need 
> to as your examples show handle scene creation and register the all the 
> IServiceModules with those.
> 
> This it does get complex, where the simply solution and the one I favour 
> is to just have a sharedRegistry that scenes can access. The whole 
> automagic came from me trying to find a compromise that met your ideas. 
> I really dislike it though, but we just need to find a compromise as we 
> both have slighly different ideas and requirements.
> 
> Thats why I would like to hear from other people.

Okay, it seems to me that the chief problem now is that MW would like to
exposed service module methods to regions 
without having to put any IScene methods in the module code, allowing it to be
used for both the region server and grid 
servers.

This is possible if all the service methods are exposed to the region. 
However, Melanie doesn't like this because it 
will expose some methods that regions should arguably not be able to get at
(such as 
IInventoryService.CreateNewUserInventory()).

I would tend to think that we shouldn't expose such service methods to
regions.

Neither side likes automagic by the core code, but I think a little bit of it
will help here.  Instead of having methods 
such as

void RegisterInterfaceToAllRegistries<T>(T iface);

we instead annotate service modules with [RegionModule] and region interfaces
with [RegionInterface].  Grid modules 
which can also provide region services are annotated in this way.  When the
core code goes to load them, the 
[RegionInterface] tagged interfaces are automatically registered with the
region registry.  This replaces 
RegisterModuleInterface().

It also requires that IServiceModule and IRegionModule are collapsed together,
by removing the IScene references in 
IRegionModule.  Instead, these are passed in via the OnNewScene() event talked
about earlier.

In this way, service/application modules that aren't interested in scenes
don't need to do any extra work apart from 
tagging the module/interfaces appropriately, avoiding the boilerplate of
separately registering the interface to each 
region.  The regions still don't have access to inter-service/non-region
interfaces.

This does require a separate service registry hidden from the Region/Scene so
that services can communicate among 
themselves (e.g. the user service needs to call the inventory service to create
new user inventories).  There would be 2 
registries in total.

Please excuse me if I haven't fully grokked all the previous posts on this
thread.





      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090226/427d08e4/attachment-0001.html>