My thoughts:
IGlobalModule {
Initialise(ModuleManager x)
Start()
Stop()
}
ModuleManager {
SceneManager,
ClientManager,
ModuleInterfaces<T>
}
From: opensim-dev-boun...@lists.berlios.de
[mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
Sent: Thursday, 26 February 2009 3:00 AM
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
... did we not just come full circle?
I believe were all in agreement here, just varying on what to call stuff and
exactly what stuff they should be connected to.
I'm confident all that will sort itself out. I think we have established a
roadmap though.
Best regards,
Stefan Andersson
Tribal Media AB
> Date: Thu, 26 Feb 2009 10:40:34 +0000
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Comms Manager
>
> What Adam said.
>
> That is precisely what I am thinking of, and what we all, in a bog
> discussion, already once agreed on, when Diva asked and we decided
> that interregion comms should be a module.
>
> I believe the comms needs of an application plugin are different
> from a region module's needs. I see no issue in haveinf _different_
> comms code in different places.
>
> I do agree that code duplication should be avoided.
>
> But I'm also taking a firm stand on CommsManager. CommsManager, as
> it is, needs tremendous effort to extend, and non-core code can not
> ever hook into it, because it has a fixed set of interfaces linked
> in. That is badness.
>
> So, I think I have a solution:
>
> Refactor all services currently in comms manager into region modules
> _or_ application plugins, depending on where it's used. Basically,
> everything that is only used by regions should be a region module.
>
> Rewrite comms manager as a registry of intefaces, that application
> plugins can register services with.
> This will be those comms manager services that are truly application
> level, means, are used by things other than regions, before regiosn
> are started, or in instances without regions.
>
> Now, each application module gets an event on creation of a scene
> anyway. So, thay can Scene.RegisterModuleInteferce<IWhatever>(this)
> with each new scene created, and offer their services to Scenes as well.
>
> If code was originally written as a region module, but is later
> found to be useful without regions (XMLRPC RemoteAdmin is one that
> comes to mind!), it can easily be moved to this interface and then
> publish itself to regions to provide region comms as well.
>
> In the case of RemoteAdmin, it's comms code (yes, a StreamHandler!)
> would be in an application plugin, exposing an IRemoteRegionAdmin to
> each region connected. A region module that does the region part of
> the work would grab that interface to access the underlying
> communications.
> That would also provide a very clean separation, as the application
> plugin can't execute anything on Scenes, because it has IScene only
> and doesn't ref Scene itself at all. Therefore it would be comms
> only, and the region module talking to it would be no comms at all.
> This seems logical because that way an instance with no active
> regions could still execute a create region command... that would be
> unavailable if no region was loaded at all!
> As Homer goes to refactor region loading and region modules, this
> will become more important.
>
> Again, I'm -1000 on having a monolithic component that requires core
> code edits to extend, but open to a solution as described above,
> which, IMHO, combines all that was said so far in a neat package.
>
> Melanie
>
>
> Stefan Andersson wrote:
> > I think that's what Melanie is leaning towards, but that would mean every
> > module would have to be connected to at least one scene.
> >
> >
> > I do believe that you would have modules doing stuff already from a setting
> > where there is no scenes loaded.
> >
> >
> >
> > The regionLoader, for example. :D
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> >
> >
> > From: a...@deepthink.com.au
> > To: opensim-dev@lists.berlios.de; michaelwr...@yahoo.co.uk
> > Date: Thu, 26 Feb 2009 05:21:48 -0500
> > Subject: Re: [Opensim-dev] Comms Manager
> >
> >
> >
> >
> >
> >
> >
> > Do we need the comms manager?
> >
> > Can't we just register them individually via Scene.RegisterModuleInterface,
> > then pull what we want when we need it?
> >
> > Adam
> >
> >
> >
> >
> > From: opensim-dev-boun...@lists.berlios.de
> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
> > Sent: Thursday, 26 February 2009 2:10 AM
> > To: Michael Wright; opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Comms Manager
> >
> > Actually, I think the various 'module types' should bee seen as reflecting
> > on what system resources will be made available to those modules - both as
> > a conveniense (better suited API entrypoints) and for security (being able
> > to set policies on modules)
> >
> > Also, I very much see these repository functions that we are looking at as
> > taking care of 'configuration' - ie, to make sure that the module code
> > don't have to take care of, or know anyhting about, the configuration of
> > other parts of the system.
> >
> > Best regards,
> > Stefan Andersson
> > Tribal Media AB
> >
> >
> >
> >
> >
> >
> >
> > Date: Thu, 26 Feb 2009 10:05:46 +0000
> > From: michaelwr...@yahoo.co.uk
> > To: opensim-dev@lists.berlios.de
> > Subject: Re: [Opensim-dev] Comms Manager
> >
> >
> >
> >
> > PS. One issue that I don't like about a lot of the Region to UGAIM code
> > that is currently in some of the region modules, is how the
> > network/transport code is mixed up with the handling of some basic features
> > like friends, presences etc. I do think we should have separate transport
> > modules.
> >
> > So maybe a IPresenceTransportService, then we could have PresenceOGS1Module
> > that implements that. And the PresenceModule uses that interface for
> > talking to and from the UGAIM servers. Rather than network code being mixed
> > in with logic code in a single module.
> >
> > Now if these are region modules or Global/comms modules is a different
> > question. I just think we should have more specialisation in the modules so
> > we can easily change the network protocols without replacing the whole sub
> > system of a feature.
> >
> > --- On Thu, 26/2/09, MW <michaelwr...@yahoo.co.uk> wrote:
> > From: MW <michaelwr...@yahoo.co.uk>
> > Subject: Re: [Opensim-dev] Comms Manager
> > To: opensim-dev@lists.berlios.de
> > Date: Thursday, 26 February, 2009, 9:44 AM
> >
> >
> >
> >
> >
> > Well I agree the name CommsManager is a bad choice and I'm all for
> > changing/getting rid of that. I don't see this as a Manager but just
> > another registery of modules. My proposal certainly isn't about
> > making/keeping all the comms code centralised. I totally agree that we
> > should have modules, and break up the current classes/interfaces in the
> > Comms Manager.
> >
> > The main differences between my proposal for comms modules and region
> > modules are comms modules are initialised before regions/scenes are created
> > and have no direct references to the scenes (although of course
> > scene/region modules could register to events on them etc). But even that
> > no direct reference could be changed.
> >
> > Also having this separate module system would also allow it to use the
> > modules from the Grid,User and messaging servers (and maybe later the
> > inventory/asset servers), which I think could help a lot to cut down the
> > duplications we have between standalone and grid servers.
> >
> > But my main issue with this concept (the comms modules and registery) is
> > there isn't really that much difference between these and region modules.
> > So is there any point in having the two systems/registeries. My concept is
> > basically a Shared module and registery but more at the application level
> > rather than the region level.
> >
> > I'm not actually really against having all the comms in region modules. But
> > do think it brings up some issues. I don't actually agree that app level
> > code/plugins shouldn't be able to access the comms to the UGAIM servers
> > without going through regions or duplicating the comms handling code. And I
> > know some of the other devs have even more issues with all the comms code
> > being in region modules. So we need to find a solution that we are all
> > happy with.
> >
> > Maybe the solution is to work on separating the shared region modules out,
> > so they are a actual different class/interface to the normal region modules
> > and maybe a different registery(?). As has been talked about in irc a lot
> > recently. But I guess these would still be accessed through regions/scenes?
> > So really no different from a usage point of view to what we have now.
> >
> >
> > --- On Thu, 26/2/09, Melanie <mela...@t-data.com> wrote:
> > From: Melanie <mela...@t-data.com>
> > Subject: Re: [Opensim-dev] Comms Manager
> > To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de
> > Date: Thursday, 26 February, 2009, 4:33 AMHi,
> >
> >
> >
> > 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@lists.berlios.de
> >
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> > _______________________________________________
> >
> > Opensim-dev mailing list
> >
> > Opensim-dev@lists.berlios.de
> >
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > _______________________________________________
> >
> > Opensim-dev mailing list
> >
> > Opensim-dev@lists.berlios.de
> >
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev@lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
