+1, looks good.
Best regards,
Stefan Andersson
Tribal Media AB
> Date: Thu, 26 Feb 2009 11:38:52 +0000
> From: mela...@t-data.com
> To: michaelwr...@yahoo.co.uk; opensim-dev@lists.berlios.de
> 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 <mela...@t-data.com> wrote:
> > From: Melanie <mela...@t-data.com>
> > Subject: Re: [Opensim-dev] Comms Manager
> > To: opensim-dev@lists.berlios.de
> > 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: 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
