... 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