[Opensim-dev] Comms Manager

Thu Feb 26 20:43:26 UTC 2009

Well I think the compromise we basically agreed on is that we go with IApplicationPlugins being able to register to the ApplicationRegistry and also (via OnRegionCreated events) to the scenes. 

And then for the service modules, we can have a loader that itself is a IApplicationPlugin that loads the service modules (IServiceModule) and does the auto registering for them. This way at least this automagic is out of the core opensimbase (etc). 

--- On Thu, 26/2/09, Melanie <melanie at t-data.com> wrote:
From: Melanie <melanie at t-data.com>
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev at lists.berlios.de
Date: Thursday, 26 February, 2009, 8:37 PM

Well, if it gets that evil, then we might as well stick with plan A. 
As long as this "All region" registration is in that specific 
application module, and not global.
I believe modules written to load into region servers should also 
handle this explicitly.

Melanie

Justin Clark-Casey wrote:
> MW wrote:
>> 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.
> 
> :(  Yeah, you're right - for some reason I forgot that you have to
explicitly name the interface when you make the 
> RegisterModuleInterface() call.  e.g.
> 
> RegisterModuleInterface<IHappyModuleMethods>(this);
> 
> I don't believe this can be achieved via reflection.
> 
> However, I think you could still indicate which interfaces should be
exposed to the region by adding attributes to them. 
>   For example, in Initialise() you could do something like
> 
> RegistryManager.RegisterModuleInterface<IHappyModuleMethods>(this);
> 
> And annotate the interfaces with something like
> 
> [ServiceInterface]
> public interface IHappyModuleMethods { ... }
> 
> In a region server, the interface would be added to the region registry. 
In a grid server, the interface would be added 
> to the grid registry.
> 
> If one wanted a non-region 'application only' interface in the
region server, then one could perhaps also add
> 
> [ApplicationInterface]
> public interface IEvilApplicationMethods { ... }
> 
> with
> 
>
RegistryManager.RegisterModuleInterface<IEvilApplicationMethods>(this);
> 
> In a region service this could be added only to the application registry
and not the region registry.  In a grid service 
> it would still be added to the single grid registry.
> 
> This is getting messy though and I'm not sure how much it buys you
over simply indicating the 'type' (service or 
> application) when you initially register it.  Mostly this all becomes a
refinement of your earlier
> 
> void RegisterInterfaceToAllRegistries<T>(T iface);
> 
>> 
>> 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.
>> 
>> 
>> 
>> 
>>
------------------------------------------------------------------------
>> 
>> _______________________________________________
>> 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

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