I still question if Global modules (that are really providing global services)
should get any references to Scene/IScene; either by events of initialisation
calls. If they are providing services, then other modules/components should be
consumers of them, so only the consumers need references to the providers. Not
the providers having references to the consumers.
But I guess that depends on what we see these global modules as being able to
do.
--- On Thu, 26/2/09, Stefan Andersson <ste...@tribalmedia.se> wrote:
From: Stefan Andersson <ste...@tribalmedia.se>
Subject: Re: [Opensim-dev] Comms Manager
To: "opensim-dev@lists.berlios.de" <opensim-dev@lists.berlios.de>
Date: Thursday, 26 February, 2009, 11:59 AM
#yiv372014547 .hmmessage P
{
margin:0px;padding:0px;}
#yiv372014547 {
font-size:10pt;font-family:Verdana;}
I'm actually with Melanie on this; using the call-back registration and event
attachment seems so much flexible and cleaner - and more in line with where the
region modules have been taking us.
Best regards,
Stefan Andersson
Tribal Media AB
> Date: Thu, 26 Feb 2009 11:56:31 +0000
> From: mela...@t-data.com
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Comms Manager
>
> You just can't let go of the centralistic *Manager idea..!
>
> IMHO, clients have no business at app level. Clients connect to
> regions through client stacks. Which can be shared modules for
> constellations where one client connection handles all regions in an
> instance.
>
> IGlobalModuleRegistry
> {
> Initialise();
> RegisterModuleInterface<T>(T instance);
> RequestModuleInterface<T>();
>
> // Triggered whan a Scene is loaded
> OnNewScene(IScene);
> InRemoveScene(IScene);
> }
>
> IScenesTrackerModule : IGlobalModule
> {
> Initialise();
> List<IScene> Scenes { get; }
> IScene FindSceneByName(string name);
> IScene FindSceneByUUID(UUID sceneID);
> .....
> }
>
> See? That scenes module is actually loaded and registers as a
> perfectly normal module inthe module registry.
> It builds and maintains a scene list automatically by means of the
> OnNewScene and OnRemoveScene events!
>
> Easy. No mess with contained classes and having to edit the
> container all the time.
>
> I hate:
>
> SomethingClass
> {
> IWhatever whatever;
> ISoWhat sowhat;
> }
>
> It cements a structure that could be inappropriate a month from now.
>
> Melanie
>
> Melanie
>
> Frisby, Adam wrote:
> > 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
> _______________________________________________
> 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
