Well I think we are very close to having a combined solution/proposal.
The two differences I see between my proposal and melanie's are the
initialisation interface for the modules and where they can register their own
interfaces with.
For initialisation we have two different interfaces(that are currently in
opensim) that could be used:
My proposal was based on IGridServiceModule (that is being used in the
User/grid/Messaging servers [work in progress]), which is :
public interface IGridServiceModule
{
void Close();
void Initialise(IGridServiceCore core);
void PostInitialise();
void RegisterHandlers(BaseHttpServer httpServer);
}
with IGridServiceCore being :
public interface IGridServiceCore
{
T Get<T>();
void RegisterInterface<T>(T iface);
bool TryGet<T>(out T iface);
BaseHttpServer GetHttpServer();
}
[Note these interfaces are at a early stage and subject to some small changes].
If we used this interface it would mean we could share modules directly between
the Grid servers and the region server. As they are generic interfaces.
But it would mean that modules couldn't register interfaces with the Scene, as
at no point would they get any reference to the Scene.
The other interface we could use (that Melanie suggests) is the
IApplicationPlugin:
public interface IApplicationPlugin : IPlugin
{
void Initialise(OpenSimBase openSim);
}
[This really needs at least a PostInitialise method, so that plugins like the
LoadRegions one can do their work in there, knowing all other
IApplicationPlugin have been initialised first]
If we go with this interface then if we want to use any plugin from the grid
servers we need to wrap them in one of these first. Which I guess isn't that
big a deal.
And it would allow us to register interfaces with the Scene. But if we are
going to register them with the scene then I guess the question is there any
need for the Global Registry? People will just get confused about which one to
register with. And would the scene still get passed a reference to the Global
Registry?
I actually see good and bad points with both approaches. So its now just a
question of ironing out the details.
[Note: My proposal includes the use of IApplicationPlugin, but only for the
IGridServiceModule loader. So the loader could be a ApplicationPlugin, that
itself loaded IGridServiceModules. But the loader could also just as easily be
directly in core.]
--- 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>, "Michael
Wright" <michaelwr...@yahoo.co.uk>
Date: Thursday, 26 February, 2009, 11:40 AM
#yiv1429688683 .hmmessage P
{
margin:0px;padding:0px;}
#yiv1429688683 {
font-size:10pt;font-family:Verdana;}
+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
