[Opensim-dev] Comms Manager

Thu Feb 26 09:42:14 UTC 2009

I would definitively think that the Region Modules wuld get a ref to the global services registry.

I totally agree with your sentiment, but I also see that you have to draw a line somewhere. This is going to sound odd coming from me, but you need to take SOME design decisions, even in a framework.

That said, I do thing this will probably morph into some kind of global service router thingy.

Most of these things will be cached proxies anyway, implementing the same interfaces that will be found of the server side.

And the server side components will (hopefully) be all StreamHandlers, so they can be freely moved between StreamHandler protocol hosts. (aka http servers or what-have-you)

Best regards,
Stefan Andersson
Tribal Media AB

PS Lots of cool stuff and good discussions going on now, let's keep up the momentum! DS.

> Date: Thu, 26 Feb 2009 04:33:59 +0000
> From: melanie at t-data.com
> To: michaelwri22 at yahoo.co.uk; opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Comms Manager
> 
> Hi,
> 
> I'm against a CommsManager class, on the grounds I'm against most 
> other *Manager classes.
> They serve as holders for stuff that seems straightforward 
> initially, but soon become monolithic molochs that make a simple 
> change, like adding a single method on a single interface, a task of 
> changing 37 files.
> 
> I don't think that any of the region comms currently in region 
> modules will need to be accessed from application plugins, since 
> they are region specific.
> 
> I would envision a system of application plugins similar to region 
> plugins, that would expose their own comms interfaces to do the sort 
> of comms the application, rather than a region, needs to do.
> 
> Forcing region comms to go through some CommsManager seems wrong.
> 
> Here, I see that specialization is about to be discarded for 
> convenience, and I don't agree. Region comms, like teleport comms, 
> don't belong in an application level comms broker, they belong in 
> region modules. So do most other comms I'm aware of. Take users, fir 
> instance. The application never talks about users, regions do. The 
> user server comms really should be a shared region module. 
> Modularisation is the key here, not centralisation.
> 
> Melanie
> 
> 
> MW wrote:
> > More and more of the Region to UGAIM comms and Region to Region comms, is being moved out of the Comms Manager and into region modules. Is this a process we should continue and move everything out of there and into Region modules? 
> > 
> > I'm a bit torn on that issue, and I think a few other people are too. We all know the current comms manager system is not the best :) And its a real pain to customise. 
> > 
> > One issue with having it all in region modules, is that everything has to go through regions to be able to use those interfaces. Making it harder for app plugins to do any comms related work. 
> > 
> > So if we decide to stick with a separate comms system (rather than moving it to region modules), how can we improve it?
> > 
> > I think the first two tasks are:
> > * to improve the interfaces/make it easier to extend.
> > * and to make it so its loaded from plugins/dlls. 
> > 
> > One simple way of allowing plugins to create and setup the Comms Manager would be making some small changes to the IApplicationPlugin interface:
> > 
> > * Add a PostInitialise method to that interface. 
> > * Then changing the LoadRegionsPlugin so that it created the regions in the IApplicationPlugin.PostInitialise call. 
> > * Which would allow us to create some SetupCommsManagerPlugins which could do its work in the IApplicationPlugin.Initialise() call.
> > 
> > [Note that brings up another issue that I want to deal with in another email soon... of how do we define which plugins are loaded. And also if there are multiple plugins, of the same type, in a single dll, how do we make some of them get loaded but not others?]
> > 
> > The next task would be to improve the interfaces of the Comms Manager and allow it to be expanded easier.
> > 
> > The current set of interfaces in the Comms manager are:
> > 
> > public class CommunicationsManager
> > {
> > public IUserService UserService
> > public IMessagingService MessageService;
> > public IGridServices GridService
> > public UserProfileCacheService UserProfileCacheService
> > public IAvatarService AvatarService
> > public IAssetCache AssetCache
> > public NetworkServersInfo NetworkServersInfo 
> > public IUserAdminService UserAdminService' 
> > public BaseHttpServer HttpServer;
> > }
> > 
> > I propose making it so the CommsManager also implements the IGridServiceCore interface which I've added to the User/Grid/Messaging servers, as part of the process of modulising them.
> > 
> > public interface IGridServiceCore
> > {
> > T Get<T>();
> > void RegisterInterface<T>(T iface);
> > bool TryGet<T>(out T iface);
> > BaseHttpServer GetHttpServer();
> > }
> > 
> > Then the components of the CommsManager can register themselves with that, and request other interfaces/Components. At the moment it would still need the old interfaces to be assigned, as external code use them. But over time, we should then change the external code so they use the TryGet<T>(out T iface) call when they want one of the interfaces/Components. 
> > 
> > So eventually the CommsManager will basically just be that interface and a set of "modules" loaded and registered with it. 
> > 
> > This brings the CommsManager more in line with the Region module system and the IClientCore and soon to be in use UGM servers system. We could even make it so it could load the same modules as the UGM servers use if we wanted to. 
> > 
> > So thoughts, comments, bad fruit being thrown wanted.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > 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/cff000f2/attachment-0001.html>