+1, looks good. Best regards, Stefan Andersson Tribal Media AB
> Date: Thu, 26 Feb 2009 11:38:52 +0000 > From: [email protected] > To: [email protected]; [email protected] > Subject: Re: [Opensim-dev] Comms Manager > > Well, I wanted to remove that extra step in the global namespace chain. > > The idea was not to supply any Scenes to these modules as a part of > startup, rather like this chain of events: > > MyApplicationModule : IMyApplicationModule, IMyRegionModuleInterface > > MyApplicationModule.Initialise(Application a) > { > a.RegisterModuleInterface<IMuApplicationModule>(this); > a.OnNewScene += OnNewScene; > } > > MyApplicationModule.OnNewScene(IScene scene) > { > scene.RegisterModuleInterface<IMyRegionModuleInterface>(this) > } > > This way, each application plugin that wants to have an interface > reachable from a scene can register one. Scenes don't need to know > the namespace path and can grab that from anywhere. Region modules > can easily access these interfaces, too. > > Application modules that expose no services to Scenes at all can > skip that step completely. > > Melanie > > > MW wrote: > > I was never suggesting that we keep CommsManager as it is. I was suggesting > > baby steps so for now there would be a commsManager, but inside it, it > > would be broken up into modules, that just registered interfaces. Then in > > time we would get rid of the current CommsManager interface and just have a > > registery of Interfaces/modules. > > > > So my proposal was: > > > > * In step one to move the CommsManager intialising code into > > applicationplugins. So we would have three plugins for that (one for > > standalone, one for gridmode and one for HyperGrid). > > * The next step was to start modulising those comms Managers so they were > > made up of modules registering their interfaces. > > * Then the next step would be to finish of the modulising the whole thing > > by spilting the modules out from the application plugins, and making one of > > the plugins a generic module loader. Then getting rid of all the old > > interfaces on the "CommsManager". > > > > So the system left would be a module registery/request interface (similar > > to in scene and IClientCore). And a module loader. > > > > But anyway, I'm still not sure these modules should be registered as region > > modules, or need to know anything about Scenes. Scenes need to know about > > them but not sure the other way around. > > > > Having scenes in the intialisation would also mean that we couldn't > > directly use modules from the Grid/User/Messaging servers. Which I would > > like to do, like I have separated the grid/user db access functions into > > DatabaseAccessModules. Really as they just read/write to db's, the same > > modules should be able to be used in grid mode and standalone mode. > > > > Really the only difference between your proposal and mine is where the > > modules/interfaces are registered with. You see them being registered > > directly with Scenes, where I see a different registery interface which > > Scenes get passed a reference to. > > > > So to use a comms module that was registered with Scene from a different > > module would mean doing : > > > > m_scene.RequestModuleInterface<IPresenceTransport>(); > > > > Where with the gloab module system it would do something like: > > > > m_scene.GlobalModules.RequestModuleInterface<IPresenceTransport>(); > > > > And the difference in the actual modules, would be that global modules > > never got passed a reference to any scene. So couldn't do anything in the > > scene. But even that could be changed I guess, if we want them to be more > > like the current shared Region modules. but it would stop the sharing of > > modules between grid and standalone mode. > > > > --- On Thu, 26/2/09, Melanie <[email protected]> wrote: > > From: Melanie <[email protected]> > > Subject: Re: [Opensim-dev] Comms Manager > > To: [email protected] > > Date: Thursday, 26 February, 2009, 10:40 AM > > > > 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: [email protected] > >> To: [email protected]; [email protected] > >> 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: [email protected] > > [mailto:[email protected]] On Behalf Of Stefan Andersson > >> Sent: Thursday, 26 February 2009 2:10 AM > >> To: Michael Wright; [email protected] > >> 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: [email protected] > >> To: [email protected] > >> 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 <[email protected]> wrote: > >> From: MW <[email protected]> > >> Subject: Re: [Opensim-dev] Comms Manager > >> To: [email protected] > >> 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 <[email protected]> wrote: > >> From: Melanie <[email protected]> > >> Subject: Re: [Opensim-dev] Comms Manager > >> To: [email protected], [email protected] > >> 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 > >> > >>> [email protected] > >> > >>> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> _______________________________________________ > >> > >> Opensim-dev mailing list > >> > >> [email protected] > >> > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> _______________________________________________ > >> > >> Opensim-dev mailing list > >> > >> [email protected] > >> > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > >> > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Opensim-dev mailing list > >> [email protected] > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Opensim-dev mailing list > > [email protected] > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
