Re: [Opensim-dev] Comms Manager
I would definitively think that the Region Modules wuld get a ref to the global
services registry.
I totally agree with your sentiment, but I also see that you have to draw a
line somewhere. This is going to sound odd coming from me, but you need to take
SOME design decisions, even in a framework.
That said, I do thing this will probably morph into some kind of global service
router thingy.
Most of these things will be cached proxies anyway, implementing the same
interfaces that will be found of the server side.
And the server side components will (hopefully) be all StreamHandlers, so they
can be freely moved between StreamHandler protocol hosts. (aka http servers or
what-have-you)
Best regards,
Stefan Andersson
Tribal Media AB
PS Lots of cool stuff and good discussions going on now, let's keep up the
momentum! DS.
Date: Thu, 26 Feb 2009 04:33:59 +
From: mela...@t-data.com
To: michaelwr...@yahoo.co.uk; opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
Hi,
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 GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(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
Re: [Opensim-dev] Comms Manager
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 AM Hi, 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
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 AM Hi, 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
Re: [Opensim-dev] Comms Manager
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 + 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
Re: [Opensim-dev] Comms Manager
I think that is basically what me and Stefan are talking about. I started off with the modules being more specialised for network/comms (and db in standalone mode), but from the discussions the idea is basically morphing into a Global module system. --- On Thu, 26/2/09, Frisby, Adam a...@deepthink.com.au wrote: From: Frisby, Adam a...@deepthink.com.au Subject: Re: [Opensim-dev] Comms Manager To: opensim-dev@lists.berlios.de opensim-dev@lists.berlios.de Date: Thursday, 26 February, 2009, 10:29 AM Maybe this is worth using as an excuse to build that “middle-module” we’ve been discussing. Something that sits between Scene and Application, a sort of ‘Supershared’ module? Then you could access the modules via maybe a shared modulemanager? 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:26 AM To: opensim-dev@lists.berlios.de; Michael Wright Subject: Re: [Opensim-dev] Comms Manager 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 + 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
Re: [Opensim-dev] Comms Manager
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.RequestModuleInterfaceIPresenceTransport(); Where with the gloab module system it would do something like: m_scene.GlobalModules.RequestModuleInterfaceIPresenceTransport(); 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.RegisterModuleInteferceIWhatever(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
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.RegisterModuleInterfaceIMuApplicationModule(this);
a.OnNewScene += OnNewScene;
}
MyApplicationModule.OnNewScene(IScene scene)
{
scene.RegisterModuleInterfaceIMyRegionModuleInterface(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.RequestModuleInterfaceIPresenceTransport();
Where with the gloab module system it would do something like:
m_scene.GlobalModules.RequestModuleInterfaceIPresenceTransport();
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.RegisterModuleInteferceIWhatever(this)
with each new scene created
Re: [Opensim-dev] Comms Manager
+1, looks good.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 11:38:52 +
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.RegisterModuleInterfaceIMuApplicationModule(this);
a.OnNewScene += OnNewScene;
}
MyApplicationModule.OnNewScene(IScene scene)
{
scene.RegisterModuleInterfaceIMyRegionModuleInterface(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.RequestModuleInterfaceIPresenceTransport();
Where with the gloab module system it would do something like:
m_scene.GlobalModules.RequestModuleInterfaceIPresenceTransport();
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
Re: [Opensim-dev] Comms Manager
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 +
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();
RegisterModuleInterfaceT(T instance);
RequestModuleInterfaceT();
// Triggered whan a Scene is loaded
OnNewScene(IScene);
InRemoveScene(IScene);
}
IScenesTrackerModule : IGlobalModule
{
Initialise();
ListIScene 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,
ModuleInterfacesT
}
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 +
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.RegisterModuleInteferceIWhatever(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
Re: [Opensim-dev] Comms Manager
And, as an afterthought:
IClientTrackerModule
{
OnNewClient(IScene scene, IClientCore client);
OnClientClose(IScene scene, IClientCore client);
}
IClientTracker : IGlobalModule, IClientTrackerModule
Initialise()
{
OnNewScene += OnNewScene;
OnRemoveScene += OnRemoveScene;
}
OnNewScene(IScene scene)
{
scene.RegisterModuleInterfaceIClientTrackerModule(this);
}
OnRemoveScene(Iscene scene) // Remove all this scene's clients
{
}
OnNewClient(IScene scene, IClientCore client)
{
}
OnClientClose(IScene scene, IClientCore client)
{
}
.
So, if you really want it, you can have it.
Melanie
Melanie wrote:
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();
RegisterModuleInterfaceT(T instance);
RequestModuleInterfaceT();
// Triggered whan a Scene is loaded
OnNewScene(IScene);
InRemoveScene(IScene);
}
IScenesTrackerModule : IGlobalModule
{
Initialise();
ListIScene 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,
ModuleInterfacesT
}
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 +
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.RegisterModuleInteferceIWhatever(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
Re: [Opensim-dev] Comms Manager
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 GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(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 +
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.RegisterModuleInterfaceIMuApplicationModule(this);
a.OnNewScene += OnNewScene;
}
MyApplicationModule.OnNewScene(IScene scene)
{
scene.RegisterModuleInterfaceIMyRegionModuleInterface(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
Re: [Opensim-dev] Comms Manager
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 +
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();
RegisterModuleInterfaceT(T instance);
RequestModuleInterfaceT();
// Triggered whan a Scene is loaded
OnNewScene(IScene);
InRemoveScene(IScene);
}
IScenesTrackerModule : IGlobalModule
{
Initialise();
ListIScene 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,
ModuleInterfacesT
}
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 +
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.RegisterModuleInteferceIWhatever(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
Re: [Opensim-dev] Comms Manager
Um, yeah, having 'Scene' as a type in anyhting outside of the Region will lead
to grief.
Suggestion:
--- OpenSim.Framework: ---
IGenericModule
{
Initialise();
PostInitialise();
}
--- OpenSim.Region.Framework: ---
IRegionModule : IGenericModule
{
OnNewScene();
OnSceneRemoved();
}
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 12:15:18 +
From: michaelwr...@yahoo.co.uk
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
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
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 +
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();
RegisterModuleInterfaceT(T instance);
RequestModuleInterfaceT();
// Triggered whan a Scene is loaded
OnNewScene(IScene);
InRemoveScene(IScene);
}
IScenesTrackerModule : IGlobalModule
{
Initialise();
ListIScene 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,
ModuleInterfacesT
}
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 +
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
Re: [Opensim-dev] Comms Manager
Hi,
Scenes _will_ be handled there, so, it might as well be facilitated,
rather than attempting an isolation level that won't work in
practice, leading to horribly ugly hacks to circumvent it later.
I have lined out 3 concrete use cases (ClientTracker, SceneTracker,
RemoteAdmin) already that would hugely profit from this. I'm sure if
I dog for 5 minutes, I would find more. Why should we make our lives
more difficult than we have to?
My concept allows a cooperating application module and it's region
module to even reside in the same DLL, making a single DLL addon
possible, even for complex services.
Melanie
MW wrote:
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 +
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();
RegisterModuleInterfaceT(T instance);
RequestModuleInterfaceT();
// Triggered whan a Scene is loaded
OnNewScene(IScene);
InRemoveScene(IScene);
}
IScenesTrackerModule : IGlobalModule
{
Initialise();
ListIScene 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,
ModuleInterfacesT
}
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 +
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
Re: [Opensim-dev] Comms Manager
I don't think Grid and Asset modules need to load into region
servers, and vice versa. At least not by the same interface. That
interchangeability makes other things that are useful almost
impossibly complex.
Melanie
Stefan Andersson wrote:
No, didn't notice that, but I question why Grid or Asset server modules
should even be aware of that, regardless of how the IScene interface looks or
what types that, in turn, pulls in.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 12:29:19 +
From: mela...@t-data.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
Hi,
note that I used IScene sxclusively?
Melanie
Stefan Andersson wrote:
Um, yeah, having 'Scene' as a type in anyhting outside of the Region will
lead to grief.
Suggestion:
--- OpenSim.Framework: ---
IGenericModule
{
Initialise();
PostInitialise();
}
--- OpenSim.Region.Framework: ---
IRegionModule : IGenericModule
{
OnNewScene();
OnSceneRemoved();
}
Best regards,
Stefan Andersson
Tribal Media AB
___
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
Re: [Opensim-dev] Comms Manager
Just a though,t but maybe we are trying to be too generic in finding a single
interface that meets all needs. We have a plugin loader (Mono.addins) that can
quite easily load different plugin types. So by using the IApplicationPlugin
system, we can have them also loading other plugin types.
If basically we are saying that we want two different Module/Interface
registeries (Global and Scene), then there is no reason that as long as all the
plugins only register interfaces with those registeries why we can't have the
multiple plugin types. So we have a type (and loader) that is able to register
event handlers so it can be informed about scenes. And we a loader that can
load the modules from the Grid servers directly.
The loaders would be minor things basically just using PluginLoader to load the
plugins.
We could say this increases the complexity, but I actually think by having
initialisation interfaces that are right for the task that the modules are
going to do makes sense.
--- 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, 12:36 PM
I don't think Grid and Asset modules need to load into region
servers, and vice versa. At least not by the same interface. That
interchangeability makes other things that are useful almost
impossibly complex.
Melanie
Stefan Andersson wrote:
No, didn't notice that, but I question why Grid or Asset server
modules should even be aware of that, regardless of how the IScene interface
looks or what types that, in turn, pulls in.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 12:29:19 +
From: mela...@t-data.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
Hi,
note that I used IScene sxclusively?
Melanie
Stefan Andersson wrote:
Um, yeah, having 'Scene' as a type in anyhting outside of
the Region will lead to grief.
Suggestion:
--- OpenSim.Framework: ---
IGenericModule
{
Initialise();
PostInitialise();
}
--- OpenSim.Region.Framework: ---
IRegionModule : IGenericModule
{
OnNewScene();
OnSceneRemoved();
}
Best regards,
Stefan Andersson
Tribal Media AB
___
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
Re: [Opensim-dev] Comms Manager
I'd have to see that, but it sounds good.
Can you illustrate?
Melanie
MW wrote:
Just a though,t but maybe we are trying to be too generic in finding a single
interface that meets all needs. We have a plugin loader (Mono.addins) that
can quite easily load different plugin types. So by using the
IApplicationPlugin system, we can have them also loading other plugin types.
If basically we are saying that we want two different Module/Interface
registeries (Global and Scene), then there is no reason that as long as all
the plugins only register interfaces with those registeries why we can't have
the multiple plugin types. So we have a type (and loader) that is able to
register event handlers so it can be informed about scenes. And we a loader
that can load the modules from the Grid servers directly.
The loaders would be minor things basically just using PluginLoader to load
the plugins.
We could say this increases the complexity, but I actually think by having
initialisation interfaces that are right for the task that the modules are
going to do makes sense.
--- 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, 12:36 PM
I don't think Grid and Asset modules need to load into region
servers, and vice versa. At least not by the same interface. That
interchangeability makes other things that are useful almost
impossibly complex.
Melanie
Stefan Andersson wrote:
No, didn't notice that, but I question why Grid or Asset server
modules should even be aware of that, regardless of how the IScene interface
looks or what types that, in turn, pulls in.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 12:29:19 +
From: mela...@t-data.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
Hi,
note that I used IScene sxclusively?
Melanie
Stefan Andersson wrote:
Um, yeah, having 'Scene' as a type in anyhting outside of
the Region will lead to grief.
Suggestion:
--- OpenSim.Framework: ---
IGenericModule
{
Initialise();
PostInitialise();
}
--- OpenSim.Region.Framework: ---
IRegionModule : IGenericModule
{
OnNewScene();
OnSceneRemoved();
}
Best regards,
Stefan Andersson
Tribal Media AB
___
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
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();
RegisterModuleInterfaceT(T instance);
RequestModuleInterfaceT();
// Triggered whan a Scene is loaded
OnNewScene(IScene);
InRemoveScene(IScene);
}
IScenesTrackerModule : IGlobalModule
{
Initialise();
ListIScene 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,
ModuleInterfacesT
}
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 +
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.RegisterModuleInteferceIWhatever(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
Re: [Opensim-dev] Comms Manager
Well I hadn't really thought out all the details but what I meant is we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads IApplicationplugins it is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new PluginLoaderIApplicationPlugin(new
ApplicationPluginInitialiser(this));
loader.Load(/OpenSim/Startup);
m_plugins = loader.Plugins;
}
and the plugin initialiser is :
public class ApplicationPluginInitialiser : PluginInitialiserBase
{
private OpenSimBase server;
public ApplicationPluginInitialiser (OpenSimBase s) { server = s; }
public override void Initialise (IPlugin plugin)
{
IApplicationPlugin p = plugin as IApplicationPlugin;
p.Initialise (server);
}
}
so there is no reason why inside a ApplicationPlugin we can't do something like:
public void Initialise(OpenSimBase openSim)
{
LoadGridServiceModules(openSim);
}
Protected virtual void LoadGridServiceModules(OpenSimBase openSimBase)
{
PluginLoaderIGridServiceModule loader =
new PluginLoaderIGridServiceModule(new
GridServicePluginInitialiser(openSimBase.GlobalRegistry));
loader.Load(/OpenSim/GridService);
m_plugins = loader.Plugins;
}
public class GridServicePluginInitialiser : PluginInitialiserBase
{
private IGridServiceCore m_core;
public ApplicationPluginInitialiser (IGridService core) { m_core =
core; }
public override void Initialise (IPlugin plugin)
{
IGridServiceModule p = plugin as IGridServiceModule;
p.Initialise (m_core);
}
}
So its then loaded the IGridServiceModules and passed them only a reference to
the GlobalRegistry (from OpenSimBase).
And for plugins/modules that want to register with scenes, we could
either have another plugin type and loader, or just use
IApplicationPlugin directly for them.
Of course this opens up the question if at any point the GlobalRegistry
should be accessable from scenes. If we are going to go with the
approach that modules that should be accessable from scenes should
register with them then I guess the answer is no. But I can see people
wanting to be able to access the GlobalRegistry from Region modules and
trying to do hacks so they can.
--- 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, 12:50 PM
I'd have to see that, but it sounds good.
Can you illustrate?
Melanie
MW wrote:
Just a though,t but maybe we are trying to be too generic in finding a
single interface that meets all needs. We have a plugin loader (Mono.addins)
that can quite easily load different plugin types. So by using the
IApplicationPlugin system, we can have them also loading other plugin types.
If basically we are saying that we want two different Module/Interface
registeries (Global and Scene), then there is no reason that as long as all the
plugins only register interfaces with those registeries why we can't have
the multiple plugin types. So we have a type (and loader) that is able to
register event handlers so it can be informed about scenes. And we a loader that
can load the modules from the Grid servers directly.
The loaders would be minor things basically just using PluginLoader to
load the plugins.
We could say this increases the complexity, but I actually think by having
initialisation interfaces that are right for the task that the modules are going
to do makes sense.
--- 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, 12:36 PM
I don't think Grid and Asset modules need to load into region
servers, and vice versa. At least not by the same interface. That
interchangeability makes other things that are useful almost
impossibly complex.
Melanie
Stefan Andersson wrote:
No, didn't notice that, but I question why Grid or Asset server
modules should even be aware of that, regardless of how the IScene
interface
looks or what types that, in turn, pulls in.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Thu, 26 Feb 2009 12:29:19 +
From: mela...@t-data.com
To: opensim-dev@lists.berlios.de
Subject: Re: [Opensim-dev] Comms Manager
Hi,
note that I used IScene sxclusively?
Melanie
Stefan Andersson wrote:
Um, yeah, having 'Scene' as a type in anyhting
outside of
the Region will lead to grief.
Suggestion:
--- OpenSim.Framework: ---
IGenericModule
Re: [Opensim-dev] Comms Manager
Hmm, I never suggested anything that would mean one scene be able to directly
access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it doesn't
actually change anything compared to how things are now with the shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the module that handled User server comms as a global service
but don't think it should have to register with all regions. I'm more in mind
that it should just register with the global registry and then region modules
than access that.
And yes nothing I have suggested stops a ApplicationModule and a RegionModule
from sharing a dll, and the ApplicationModule starts up and registers the
RegionModule or whatever. I just don't think its the solution for everything.
So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads IApplicationplugins it
is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new PluginLoaderIApplicationPlugin(new
ApplicationPluginInitialiser(this));
loader.Load(/OpenSim/Startup);
m_plugins = loader.Plugins;
}
and the plugin initialiser is :
public class ApplicationPluginInitialiser : PluginInitialiserBase
{
private OpenSimBase server;
public ApplicationPluginInitialiser (OpenSimBase s) { server = s;
}
public override void Initialise (IPlugin plugin)
{
IApplicationPlugin p = plugin as IApplicationPlugin;
p.Initialise (server);
}
}
so there is no reason why inside a ApplicationPlugin we can't do
something like:
public void Initialise(OpenSimBase openSim)
{
LoadGridServiceModules(openSim);
}
Protected virtual void LoadGridServiceModules(OpenSimBase openSimBase)
{
PluginLoaderIGridServiceModule loader =
new PluginLoaderIGridServiceModule(new
GridServicePluginInitialiser(openSimBase.GlobalRegistry));
loader.Load(/OpenSim/GridService);
m_plugins = loader.Plugins;
}
public class GridServicePluginInitialiser : PluginInitialiserBase
{
private IGridServiceCore m_core;
public ApplicationPluginInitialiser (IGridService core) { m_core =
core; }
public override void Initialise (IPlugin plugin)
{
IGridServiceModule p = plugin as IGridServiceModule;
p.Initialise (m_core);
}
}
So its then loaded the IGridServiceModules and passed them only a
reference to the GlobalRegistry (from OpenSimBase).
And for plugins/modules that want to register with scenes, we could
either have another plugin type and loader, or just use
IApplicationPlugin directly for them.
Of course this opens up the question if at any point the GlobalRegistry
should be accessable from scenes. If we are going to go with the
approach that modules that should be accessable from scenes should
register with them then I guess the answer is no. But I can see people
wanting to be able to access the GlobalRegistry from Region modules and
trying to do hacks so they can.
--- On Thu, 26/2/09, Melanie mela...@t-data.com wrote:
From: Melanie mela...@t-data.com
Subject: Re: [Opensim-dev
Re: [Opensim-dev] Comms Manager
If you want to be more flexible, then my approach is better. In your
model, a global module has not way to _prevent_ being accessed by Scene.
I believe Scene has no business holding a ref to the application, or
accessing the global registry.
In my design, each module has the power to decide whether it wants
to be accessible from Scene and what methods it exposes to it. Your
method reduces that duality into a single interface and makes all
scenes be able to access all methods on all interfaces. That leaves
no room for isolation, even if a module writer would want it.
I believe the modules _should_ indeed register with each scene in a
callback, and that would actually let them register only to specific
scenes if they wanted to. More flexibility yet.
Melanie
MW wrote:
Hmm, I never suggested anything that would mean one scene be able to directly
access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it
doesn't actually change anything compared to how things are now with the
shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the module that handled User server comms as a global service
but don't think it should have to register with all regions. I'm more in mind
that it should just register with the global registry and then region modules
than access that.
And yes nothing I have suggested stops a ApplicationModule and a RegionModule
from sharing a dll, and the ApplicationModule starts up and registers the
RegionModule or whatever. I just don't think its the solution for everything.
So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads IApplicationplugins it
is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new PluginLoaderIApplicationPlugin(new
ApplicationPluginInitialiser(this));
loader.Load(/OpenSim/Startup);
m_plugins = loader.Plugins;
}
and the plugin initialiser is :
public class ApplicationPluginInitialiser : PluginInitialiserBase
{
private OpenSimBase server;
public ApplicationPluginInitialiser (OpenSimBase s) { server = s;
}
public override void Initialise (IPlugin plugin)
{
IApplicationPlugin p = plugin as IApplicationPlugin;
p.Initialise (server);
}
}
so there is no reason why inside a ApplicationPlugin we can't do
something like:
public void Initialise(OpenSimBase openSim)
{
LoadGridServiceModules(openSim);
}
Protected virtual void LoadGridServiceModules(OpenSimBase openSimBase)
{
PluginLoaderIGridServiceModule loader =
new PluginLoaderIGridServiceModule(new
GridServicePluginInitialiser(openSimBase.GlobalRegistry));
loader.Load(/OpenSim/GridService);
m_plugins = loader.Plugins;
}
public class GridServicePluginInitialiser : PluginInitialiserBase
{
private IGridServiceCore m_core;
public ApplicationPluginInitialiser (IGridService core) { m_core =
core; }
public override void Initialise (IPlugin plugin)
{
IGridServiceModule p = plugin as IGridServiceModule
Re: [Opensim-dev] Comms Manager
We also should think of baby steps in how we could refactor the current setup.
We do have the CommsManager if we like it or not, and I do think the easiest
way to refactor that is to make it into a global Registry that can be accessed
from the regions.
That requires the least amount of work to start on the process of cleaning the
whole system up. Maybe at a later date we might decide to remove the access to
the global registry from the scenes (but at this time, I'm against that)
--- 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, 1:28 PM
Hmm, I never suggested anything that would mean one scene be able to directly
access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it doesn't
actually change anything compared to how things are now with the shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the module that handled User server comms as a global service
but don't think it should have to register with all regions. I'm more in mind
that it should just register with the global registry and then region modules
than access that.
And yes nothing I have suggested stops a ApplicationModule and a RegionModule
from sharing a dll, and the ApplicationModule starts up and registers the
RegionModule or whatever. I just don't think its the solution for everything.
So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads IApplicationplugins it
is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new PluginLoaderIApplicationPlugin(new
ApplicationPluginInitialiser(this));
loader.Load(/OpenSim/Startup);
m_plugins = loader.Plugins;
}
and the plugin initialiser is :
public class ApplicationPluginInitialiser : PluginInitialiserBase
{
private OpenSimBase server;
public ApplicationPluginInitialiser (OpenSimBase s) { server = s;
}
public override void Initialise
(IPlugin plugin)
{
IApplicationPlugin p = plugin as IApplicationPlugin;
p.Initialise (server);
}
}
so there is no reason why inside a ApplicationPlugin we can't do
something like:
public void Initialise(OpenSimBase openSim)
{
LoadGridServiceModules(openSim);
}
Protected virtual void LoadGridServiceModules(OpenSimBase openSimBase)
{
PluginLoaderIGridServiceModule loader =
new PluginLoaderIGridServiceModule(new
GridServicePluginInitialiser(openSimBase.GlobalRegistry));
loader.Load(/OpenSim/GridService);
m_plugins = loader.Plugins;
}
public class GridServicePluginInitialiser : PluginInitialiserBase
{
private IGridServiceCore m_core;
public ApplicationPluginInitialiser (IGridService core) { m_core =
core; }
public override void Initialise (IPlugin plugin)
{
IGridServiceModule p = plugin as IGridServiceModule;
p.Initialise (m_core);
}
}
So its then loaded the IGridServiceModules and passed them only a
reference to the GlobalRegistry
Re: [Opensim-dev] Comms Manager
Well actually my suggestion of supporting multiple plugin interfaces allowed
both approaches and left everything up to the module creator.
But I think we should wait for input from others now as we aren't really
getting anywhere on the fine details. I think we have the basis of a system
just need to get other peope's input so we can work out those small details.
Like the main one being should the global registry be accessable from regions.
And if we decide it shouldn't, is it okay for it be in the short term so we can
refactor comms manager easiest. ie comms manager becomes the global registry
for 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, 1:36 PM
If you want to be more flexible, then my approach is better. In your
model, a global module has not way to _prevent_ being accessed by Scene.
I believe Scene has no business holding a ref to the application, or
accessing the global registry.
In my design, each module has the power to decide whether it wants
to be accessible from Scene and what methods it exposes to it. Your
method reduces that duality into a single interface and makes all
scenes be able to access all methods on all interfaces. That leaves
no room for isolation, even if a module writer would want it.
I believe the modules _should_ indeed register with each scene in a
callback, and that would actually let them register only to specific
scenes if they wanted to. More flexibility yet.
Melanie
MW wrote:
Hmm, I never suggested anything that would mean one scene be able to
directly access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it
doesn't actually change anything compared to how things are now with the
shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the module that handled User server comms as a global service but
don't think it should have to register with all regions. I'm more in
mind that it should just register with the global registry and then region
modules than access that.
And yes nothing I have suggested stops a ApplicationModule and a
RegionModule from sharing a dll, and the ApplicationModule starts up and
registers the RegionModule or whatever. I just don't think its the solution
for everything. So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant
is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads
IApplicationplugins it
is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new PluginLoaderIApplicationPlugin(new
ApplicationPluginInitialiser(this));
loader.Load(/OpenSim/Startup);
m_plugins = loader.Plugins;
}
and the plugin initialiser is :
public class ApplicationPluginInitialiser : PluginInitialiserBase
{
private OpenSimBase server;
public ApplicationPluginInitialiser (OpenSimBase s) { server =
s;
}
public override void Initialise (IPlugin plugin)
{
IApplicationPlugin p = plugin as IApplicationPlugin;
p.Initialise (server);
}
}
so there is no reason why inside a ApplicationPlugin we can't do
something like:
public void Initialise(OpenSimBase openSim
Re: [Opensim-dev] Comms Manager
I know I said we should wait for other people to give some input, but just one
last suggestion.
Maybe we should have three registeries. A ApplicationServiceRegistry that is
only accessable from the application level), A SharedServiceRegistry that is
accessable from the application and all scenes/regions. And then the current
Registry in Scene.
Then its upto the modules/components/plugins to which registries they want to
register.
And certain plugin types might only get references allowing them to register to
certain registeries.
--- 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, 1:48 PM
Well actually my suggestion of supporting multiple plugin interfaces allowed
both approaches and left everything up to the module creator.
But I think we should wait for input from others now as we aren't really
getting anywhere on the fine details. I think we have the basis of a system
just need to get other peope's input so we can work out those small details.
Like the main one being should the global registry be accessable from regions.
And if we decide it shouldn't, is it okay for it be in the short term so we can
refactor comms manager easiest. ie comms manager becomes the global registry
for 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, 1:36 PM
If you want to be more flexible, then my approach is better. In your
model, a global module has not way to _prevent_ being accessed by Scene.
I believe Scene has no business holding a ref to the application, or
accessing the global registry.
In my design, each module has the power to decide whether it wants
to be accessible from Scene and what methods it exposes to it. Your
method reduces that duality into a single interface and makes all
scenes be able to access all methods on all interfaces. That leaves
no room for isolation, even if a module writer would want it.
I believe the modules _should_ indeed register with each scene in a
callback, and that would actually let them register only to specific
scenes if they wanted to. More flexibility
yet.
Melanie
MW wrote:
Hmm, I never suggested anything that would mean one scene be able to
directly access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it
doesn't actually change anything compared to how things are now with the
shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the
module that handled User server comms as a global service but
don't think it should have to register with all regions. I'm more in
mind that it should just register with the global registry and then region
modules than access that.
And yes nothing I have suggested stops a ApplicationModule and a
RegionModule from sharing a dll, and the ApplicationModule starts up and
registers the RegionModule or whatever. I just don't think its the solution
for everything. So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant
is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads
IApplicationplugins it
is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new
Re: [Opensim-dev] Comms Manager
I think introducing cruft to fix cruft is no good.
I think that the new system should be brought in alongside the old
as a clean start, and then services migrated to it, rather than
trying to morph CommsManager.
Melanie
MW wrote:
We also should think of baby steps in how we could refactor the current
setup. We do have the CommsManager if we like it or not, and I do think the
easiest way to refactor that is to make it into a global Registry that can be
accessed from the regions.
That requires the least amount of work to start on the process of cleaning
the whole system up. Maybe at a later date we might decide to remove the
access to the global registry from the scenes (but at this time, I'm against
that)
--- 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, 1:28 PM
Hmm, I never suggested anything that would mean one scene be able to directly
access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it
doesn't actually change anything compared to how things are now with the
shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the module that handled User server comms as a global service
but don't think it should have to register with all regions. I'm more in mind
that it should just register with the global registry and then region modules
than access that.
And yes nothing I have suggested stops a ApplicationModule and a RegionModule
from sharing a dll, and the ApplicationModule starts up and registers the
RegionModule or whatever. I just don't think its the solution for everything.
So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses it.
That is much cleaner.
Melanie
MW wrote:
Well I hadn't really thought out all the details but what I meant is
we
can have a IApplicationPlugin that can load other plugin types itself.
So if we look at the code in OpenSimBase that loads IApplicationplugins it
is:
protected virtual void LoadPlugins()
{
PluginLoaderIApplicationPlugin loader =
new PluginLoaderIApplicationPlugin(new
ApplicationPluginInitialiser(this));
loader.Load(/OpenSim/Startup);
m_plugins = loader.Plugins;
}
and the plugin initialiser is :
public class ApplicationPluginInitialiser : PluginInitialiserBase
{
private OpenSimBase server;
public ApplicationPluginInitialiser (OpenSimBase s) { server = s;
}
public override void Initialise
(IPlugin plugin)
{
IApplicationPlugin p = plugin as IApplicationPlugin;
p.Initialise (server);
}
}
so there is no reason why inside a ApplicationPlugin we can't do
something like:
public void Initialise(OpenSimBase openSim)
{
LoadGridServiceModules(openSim);
}
Protected virtual void LoadGridServiceModules(OpenSimBase openSimBase)
{
PluginLoaderIGridServiceModule loader =
new PluginLoaderIGridServiceModule(new
GridServicePluginInitialiser(openSimBase.GlobalRegistry));
loader.Load(/OpenSim/GridService);
m_plugins = loader.Plugins;
}
public class GridServicePluginInitialiser : PluginInitialiserBase
{
private IGridServiceCore m_core;
public ApplicationPluginInitialiser (IGridService core
Re: [Opensim-dev] Comms Manager
I think that would introduce a layer of complexity in core, where i
think that complexity (e.g. registering to scenes) s better off
distributed inside the modules that actually need it. Keep it
simple. I believe my approach is what will work with the least
amount of core code, and provide the greatest flexibility.
Melanie
MW wrote:
I know I said we should wait for other people to give some input, but just
one last suggestion.
Maybe we should have three registeries. A ApplicationServiceRegistry that is
only accessable from the application level), A SharedServiceRegistry that is
accessable from the application and all scenes/regions. And then the current
Registry in Scene.
Then its upto the modules/components/plugins to which registries they want to
register.
And certain plugin types might only get references allowing them to register
to certain registeries.
--- 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, 1:48 PM
Well actually my suggestion of supporting multiple plugin interfaces allowed
both approaches and left everything up to the module creator.
But I think we should wait for input from others now as we aren't really
getting anywhere on the fine details. I think we have the basis of a system
just need to get other peope's input so we can work out those small details.
Like the main one being should the global registry be accessable from
regions. And if we decide it shouldn't, is it okay for it be in the short
term so we can refactor comms manager easiest. ie comms manager becomes the
global registry for 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, 1:36 PM
If you want to be more flexible, then my approach is better. In your
model, a global module has not way to _prevent_ being accessed by Scene.
I believe Scene has no business holding a ref to the application, or
accessing the global registry.
In my design, each module has the power to decide whether it wants
to be accessible from Scene and what methods it exposes to it. Your
method reduces that duality into a single interface and makes all
scenes be able to access all methods on all interfaces. That leaves
no room for isolation, even if a module writer would want it.
I believe the modules _should_ indeed register with each scene in a
callback, and that would actually let them register only to specific
scenes if they wanted to. More flexibility
yet.
Melanie
MW wrote:
Hmm, I never suggested anything that would mean one scene be able to
directly access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(out T iface);
}
[Which would be in OpenSim.Framework or wherever]
So if we did want a Scene to be able to access it, all it would need on
creation is pass a IGridServiceCore reference in its parameters. So it
doesn't actually change anything compared to how things are now with the
shared modules.
I just am still not sure that GlobalServices should have to indivudally
register with the Scenes even if they want to provide services to region
modules. I see the
module that handled User server comms as a global service but
don't think it should have to register with all regions. I'm more in
mind that it should just register with the global registry and then region
modules than access that.
And yes nothing I have suggested stops a ApplicationModule and a
RegionModule from sharing a dll, and the ApplicationModule starts up and
registers the RegionModule or whatever. I just don't think its the solution
for everything. So am trying to think of way of being more flexible.
--- 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, 1:14 PM
Hi,
one of the paradigms is that no Scene should directly access another
Scene.
Therefore, providing a clear path to the global registry from the
DLL Scene is in would break that isolation.
Really, global modules that want/need to be accessed from Scene can
register an interface there.
Also, processing will probably need to be broken up into a part that
has the Scene type and a part that doesn't.
This is where I think a global module and a region module as well as
the interfaces used between them can share a dll.
The global module would register that interface on the region, and
the region modules uses
Re: [Opensim-dev] Comms Manager
I still think we should have a SharedRegistry that all Scenes have access to.
Some of the current shared RegionModules could move to using it as well. And I
know some of the other devs want one to; Adam and Stefan were talking about one
in IRC the other day.
But if we all agree that we actually don't want one of them. Then a possible
compromise might be adding a extra RegisterToAllRegistries method to the core
Global registry interface so something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
void RegisterInterfaceToAllRegistriesT(T iface);
bool TryGetT(out T iface);
}
This would add the interface to a list, that then is copied to each region
that starts up, so a kind of auto registration. Without the modules having to
be given scene references if the interface type they are using doesn't support
that.
So all we would be doing is making OpenSimBase implement that interface and
provide the support for the auto registration to Scenes with
RegisterInterfaceToAllRegistries. Any module/plugin using RegisterInterface
would only register with the Global/Application registry that wouldn't be
accessable from regions. Of course they could then manually register themselves
with the regions.
I just really dislike trying Scene/IScene into all the plugin interfaces. I'm
fine with plugins being able to access them via a IApplicationPlugin if thats
the way the plugin creator did things. But I also want a more generic module
type that can still offer services to regions/scenes. Most likely using the
plugin loader approach I mentioned earlier. If this extra plugin loading was
done by a ApplicationPlugin then anyone who didn't want to support those types
could easily remove that loader.
--- 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, 2:40 PM
I think that would introduce a layer of complexity in core, where i think that
complexity (e.g. registering to scenes) s better off distributed inside the
modules that actually need it. Keep it simple. I believe my approach is what
will work with the least amount of core code, and provide the greatest
flexibility.
Melanie
MW wrote:
I know I said we should wait for other people to give some input, but just
one last suggestion.
Maybe we should have three registeries. A ApplicationServiceRegistry that
is only accessable from the application level), A SharedServiceRegistry that is
accessable from the application and all scenes/regions. And then the current
Registry in Scene.
Then its upto the modules/components/plugins to which registries they want
to register.
And certain plugin types might only get references allowing them to
register to certain registeries.
--- 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, 1:48 PM
Well actually my suggestion of supporting multiple plugin interfaces
allowed both approaches and left everything up to the module creator.
But I think we should wait for input from others now as we aren't
really getting anywhere on the fine details. I think we have the basis of a
system just need to get other peope's input so we can work out those small
details. Like the main one being should the global registry be accessable from
regions. And if we decide it shouldn't, is it okay for it be in the short
term so we can refactor comms manager easiest. ie comms manager becomes the
global registry for 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, 1:36 PM
If you want to be more flexible, then my approach is better. In your
model, a global module has not way to _prevent_ being accessed by Scene.
I believe Scene has no business holding a ref to the application, or
accessing the global registry.
In my design, each module has the power to decide whether it wants to be
accessible from Scene and what methods it exposes to it. Your method reduces
that duality into a single interface and makes all scenes be able to access all
methods on all interfaces. That leaves no room for isolation, even if a module
writer would want it.
I believe the modules _should_ indeed register with each scene in a
callback, and that would actually let them register only to specific scenes if
they wanted to. More flexibility
yet.
Melanie
MW wrote:
Hmm, I never suggested anything that would mean one scene be able to
directly access another.
I see the GlobalRegistry as a very basic interface something like:
public interface IGridServiceCore
Re: [Opensim-dev] Comms Manager
In my (much simpler) design, the IScene won't even need to be on the
interface. All that is needed is for the core (Scene loader) to
provide the OnNewScene and OnRemoveScene events. In my example, I
placed those on the interface, that was actually not needed at all.
I do believe that the registration to scenes should be done by a
piece of boilerplate code int he module itself, and not
automagically. The automagical registration leaves no room to expose
a _different_ interface to the scene from what is exposed to the
application. Since many application level methods would be useless
to Scenes and may be harmful, and vice versa, the two-interface
approach I outlined seems cleaner.
In the simplest case:
MyApplicationModule : IApplicationPlugin
{
IApplicationPlugin members
}
Nothing special there, clean and simple
Then, if we want to be notified about scenes to register to them,
grab the region loader interface:
IRegionLoader loader =
application.RequestModuleInterfaceIRegionLoader();
and _then_ hook from there:
loader.OnNewScene += OnNewSceneHandler
Which doesn't have to be on any interface.
It would just be a class member:
private void OnNewSceneHandler(IScene scene)
{
}
and that could then call the interface registration method
That is clean, doesn't push Scenes into modules that don't want
them, allows exposing interfaces to Scenes with a minimum of
boilerplate, and has no automagic that is hard to understand or brittle.
Melanie
MW wrote:
I still think we should have a SharedRegistry that all Scenes have access to.
Some of the current shared RegionModules could move to using it as well. And
I know some of the other devs want one to; Adam and Stefan were talking about
one in IRC the other day.
But if we all agree that we actually don't want one of them. Then a possible
compromise might be adding a extra RegisterToAllRegistries method to the core
Global registry interface so something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
void RegisterInterfaceToAllRegistriesT(T iface);
bool TryGetT(out T iface);
}
This would add the interface to a list, that then is copied to each region
that starts up, so a kind of auto registration. Without the modules having to
be given scene references if the interface type they are using doesn't
support that.
So all we would be doing is making OpenSimBase implement that interface and
provide the support for the auto registration to Scenes with
RegisterInterfaceToAllRegistries. Any module/plugin using RegisterInterface
would only register with the Global/Application registry that wouldn't be
accessable from regions. Of course they could then manually register
themselves with the regions.
I just really dislike trying Scene/IScene into all the plugin interfaces. I'm
fine with plugins being able to access them via a IApplicationPlugin if thats
the way the plugin creator did things. But I also want a more generic module
type that can still offer services to regions/scenes. Most likely using the
plugin loader approach I mentioned earlier. If this extra plugin loading was
done by a ApplicationPlugin then anyone who didn't want to support those
types could easily remove that loader.
--- 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, 2:40 PM
I think that would introduce a layer of complexity in core, where i think that
complexity (e.g. registering to scenes) s better off distributed inside the
modules that actually need it. Keep it simple. I believe my approach is what
will work with the least amount of core code, and provide the greatest
flexibility.
Melanie
MW wrote:
I know I said we should wait for other people to give some input, but just
one last suggestion.
Maybe we should have three registeries. A ApplicationServiceRegistry that
is only accessable from the application level), A SharedServiceRegistry that
is
accessable from the application and all scenes/regions. And then the current
Registry in Scene.
Then its upto the modules/components/plugins to which registries they want
to register.
And certain plugin types might only get references allowing them to
register to certain registeries.
--- 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, 1:48 PM
Well actually my suggestion of supporting multiple plugin interfaces
allowed both approaches and left everything up to the module creator.
But I think we should wait for input from others now as we aren't
really getting anywhere on the fine details. I think we have the basis of a
system just need
Re: [Opensim-dev] Comms Manager
Well I still want to be able to have a module that implements a very simple
generic interface something like:
public interface IGridServiceModule
{
void Close();
void Initialise(IGridServiceCore core);
void PostInitialise();
}
And all it has to do is call a register function on IGridServiceCore that makes
it available to the application and scene. I don't want to have to have a
separate IApplicationPlugin wrapper around all these modules. But I guess we
could do some hacking in a IApplicationPlugin based module loader (for these
IGridServiceModule types). Its just not very clean to have to do extra trickery
in a loader to be able to load and register modules that don't need to have
references to IScene.
--- 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, 5:05 PM
In my (much simpler) design, the IScene won't even need to be on the
interface. All that is needed is for the core (Scene loader) to provide the
OnNewScene and OnRemoveScene events. In my example, I placed those on the
interface, that was actually not needed at all.
I do believe that the registration to scenes should be done by a piece of
boilerplate code int he module itself, and not automagically. The automagical
registration leaves no room to expose a _different_ interface to the scene from
what is exposed to the application. Since many application level methods would
be useless to Scenes and may be harmful, and vice versa, the two-interface
approach I outlined seems cleaner.
In the simplest case:
MyApplicationModule : IApplicationPlugin
{
IApplicationPlugin members
}
Nothing special there, clean and simple
Then, if we want to be notified about scenes to register to them, grab the
region loader interface:
IRegionLoader loader =
application.RequestModuleInterfaceIRegionLoader();
and _then_ hook from there:
loader.OnNewScene += OnNewSceneHandler
Which doesn't have to be on any interface.
It would just be a class member:
private void OnNewSceneHandler(IScene scene)
{
}
and that could then call the interface registration method
That is clean, doesn't push Scenes into modules that don't want them,
allows exposing interfaces to Scenes with a minimum of boilerplate, and has no
automagic that is hard to understand or brittle.
Melanie
MW wrote:
I still think we should have a SharedRegistry that all Scenes have access
to. Some of the current shared RegionModules could move to using it as well. And
I know some of the other devs want one to; Adam and Stefan were talking about
one in IRC the other day.
But if we all agree that we actually don't want one of them. Then a
possible compromise might be adding a extra RegisterToAllRegistries method to
the core Global registry interface so something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
void RegisterInterfaceToAllRegistriesT(T iface);
bool TryGetT(out T iface);
}
This would add the interface to a list, that then is copied to
each region that starts up, so a kind of auto registration. Without the modules
having to be given scene references if the interface type they are using
doesn't support that.
So all we would be doing is making OpenSimBase implement that interface
and provide the support for the auto registration to Scenes with
RegisterInterfaceToAllRegistries. Any module/plugin using RegisterInterface
would only register with the Global/Application registry that wouldn't be
accessable from regions. Of course they could then manually register themselves
with the regions.
I just really dislike trying Scene/IScene into all the plugin interfaces.
I'm fine with plugins being able to access them via a IApplicationPlugin if
thats the way the plugin creator did things. But I also want a more generic
module type that can still offer services to regions/scenes. Most likely using
the plugin loader approach I mentioned earlier. If this extra plugin loading was
done by a ApplicationPlugin then anyone who didn't want to support those
types could easily remove that loader.
--- 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, 2:40 PM
I think that would introduce a layer of complexity in core, where i think
that
complexity (e.g. registering to scenes) s better off distributed inside
the
modules that actually need it. Keep it simple. I believe my approach is
what
will work with the least amount of core code, and provide the greatest
flexibility.
Melanie
MW wrote:
I know I said we should wait for other people to give some input, but
just
one last suggestion.
Maybe we should have three
Re: [Opensim-dev] Comms Manager
I'm not objecting to your module. if IGridServiceCore then has the
registry, then that is fone. I'm not dead set on IApplicationModule,
it is simply the only one I know at that level.
So, define:
IGridServiceCore
{
...
void RegisterModuleInterfaceT(T module);
void UnregisterModuleInterfaceT();
T RequesModuleInterfaceT();
...
}
and the make IRegionLoader be one of those interfaces, and have
IRegionLoader
{
...
event NewScene OnNewScene;
event RemoveScene OnRemoveScene;
...
}
so you can use:
PostInitialise()
{
IRegionLoader loader = core.RequestModuleInterfaceIRegionLoader();
loader.OnNewScene += NewScene;
}
private void NewScene(IScene scene)
{
}
and that will solve it.
I am objecting only to the attempts to create a complex solution for
a simple problem, when the above is the simple solution we already
mostly have.
Melanie
MW wrote:
Well I still want to be able to have a module that implements a very simple
generic interface something like:
public interface IGridServiceModule
{
void Close();
void Initialise(IGridServiceCore core);
void PostInitialise();
}
And all it has to do is call a register function on IGridServiceCore that
makes it available to the application and scene. I don't want to have to have
a separate IApplicationPlugin wrapper around all these modules. But I guess
we could do some hacking in a IApplicationPlugin based module loader (for
these IGridServiceModule types). Its just not very clean to have to do extra
trickery in a loader to be able to load and register modules that don't need
to have references to IScene.
--- 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, 5:05 PM
In my (much simpler) design, the IScene won't even need to be on the
interface. All that is needed is for the core (Scene loader) to provide the
OnNewScene and OnRemoveScene events. In my example, I placed those on the
interface, that was actually not needed at all.
I do believe that the registration to scenes should be done by a piece of
boilerplate code int he module itself, and not automagically. The automagical
registration leaves no room to expose a _different_ interface to the scene
from
what is exposed to the application. Since many application level methods would
be useless to Scenes and may be harmful, and vice versa, the two-interface
approach I outlined seems cleaner.
In the simplest case:
MyApplicationModule : IApplicationPlugin
{
IApplicationPlugin members
}
Nothing special there, clean and simple
Then, if we want to be notified about scenes to register to them, grab the
region loader interface:
IRegionLoader loader =
application.RequestModuleInterfaceIRegionLoader();
and _then_ hook from there:
loader.OnNewScene += OnNewSceneHandler
Which doesn't have to be on any interface.
It would just be a class member:
private void OnNewSceneHandler(IScene scene)
{
}
and that could then call the interface registration method
That is clean, doesn't push Scenes into modules that don't want them,
allows exposing interfaces to Scenes with a minimum of boilerplate, and has no
automagic that is hard to understand or brittle.
Melanie
MW wrote:
I still think we should have a SharedRegistry that all Scenes have access
to. Some of the current shared RegionModules could move to using it as well.
And
I know some of the other devs want one to; Adam and Stefan were talking about
one in IRC the other day.
But if we all agree that we actually don't want one of them. Then a
possible compromise might be adding a extra RegisterToAllRegistries method to
the core Global registry interface so something like:
public interface IGridServiceCore
{
T GetT();
void RegisterInterfaceT(T iface);
void RegisterInterfaceToAllRegistriesT(T iface);
bool TryGetT(out T iface);
}
This would add the interface to a list, that then is copied to
each region that starts up, so a kind of auto registration. Without the
modules
having to be given scene references if the interface type they are using
doesn't support that.
So all we would be doing is making OpenSimBase implement that interface
and provide the support for the auto registration to Scenes with
RegisterInterfaceToAllRegistries. Any module/plugin using RegisterInterface
would only register with the Global/Application registry that wouldn't be
accessable from regions. Of course they could then manually register
themselves
with the regions.
I just really dislike trying Scene/IScene into all the plugin interfaces.
I'm fine with plugins being able to access them via a IApplicationPlugin if
thats the way the plugin creator did things. But I also want a more generic
module type that can still offer
Re: [Opensim-dev] Comms Manager
I'm not actually bothered about the interface per se. What I require is to be
able to dynamically load generic modules that no where in that module does it
know about IScene/Scene.
I actually see your approach as complex because it demands they need to know
how to register to a scene themselves when these types shouldn't need to know.
The types of modules I mean are ones where they just want to register with the
Core/Application and be accessed from anywhere in the application.
Of course this module type doesn't fit all needs, but thats what I'm saying its
not right to try to find a single solution that fits all needs and turns out to
be more complex than some modules require. And we shouldn't rule out such
generic modules.
Now we could still do meet the above requirement with you system, but it would
mean doing some automagic in a ApplicationPlugin (or whatever interface they
used) loader.
As the loader would have to provide its own IServiceCore implementation, that
it passed to the IServiceModules that it loaded, then it would need to as your
examples show handle scene creation and register the all the IServiceModules
with those.
This it does get complex, where the simply solution and the one I favour is to
just have a sharedRegistry that scenes can access. The whole automagic came
from me trying to find a compromise that met your ideas. I really dislike it
though, but we just need to find a compromise as we both have slighly different
ideas and requirements.
Thats why I would like to hear from other people.
--- 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, 5:28 PM
I'm not objecting to your module. if IGridServiceCore then has the
registry, then that is fone. I'm not dead set on IApplicationModule,
it is simply the only one I know at that level.
So, define:
IGridServiceCore
{
...
void RegisterModuleInterfaceT(T module);
void UnregisterModuleInterfaceT();
T RequesModuleInterfaceT();
...
}
and the make IRegionLoader be one of those interfaces, and have
IRegionLoader
{
...
event NewScene OnNewScene;
event RemoveScene OnRemoveScene;
...
}
so you can use:
PostInitialise()
{
IRegionLoader loader = core.RequestModuleInterfaceIRegionLoader();
loader.OnNewScene += NewScene;
}
private void NewScene(IScene scene)
{
}
and that will solve it.
I am objecting only to the attempts to create a complex solution for
a simple problem, when the above is the simple solution we already
mostly have.
Melanie
MW wrote:
Well I still want to be able to have a module that implements a very
simple generic interface something like:
public interface IGridServiceModule
{
void Close();
void Initialise(IGridServiceCore core);
void PostInitialise();
}
And all it has to do is call a register function on IGridServiceCore that
makes it available to the application and scene. I don't want to have to
have a separate IApplicationPlugin wrapper around all these modules. But I guess
we could do some hacking in a IApplicationPlugin based module loader
(for these IGridServiceModule types). Its just not very clean to have to do
extra trickery in a loader to be able to load and register modules that
don't need to have references to IScene.
--- 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, 5:05 PM
In my (much simpler) design, the IScene won't even need to be on the
interface. All that is needed is for the core (Scene loader) to provide
the
OnNewScene and OnRemoveScene events. In my example, I placed those on the
interface, that was actually not needed at all.
I do believe that the registration to scenes should be done by a piece of
boilerplate code int he module itself, and not automagically. The
automagical
registration leaves no room to expose a _different_ interface to the scene
from
what is exposed to the application. Since many application level methods
would
be useless to Scenes and may be harmful, and vice versa, the two-interface
approach I outlined seems cleaner.
In the simplest case:
MyApplicationModule : IApplicationPlugin
{
IApplicationPlugin members
}
Nothing special there, clean and simple
Then, if we want to be notified about scenes to register to them, grab the
region loader interface:
IRegionLoader loader =
application.RequestModuleInterfaceIRegionLoader();
and _then_ hook from there:
loader.OnNewScene += OnNewSceneHandler
Which doesn't have to be on any interface.
It would just be a class member:
private void OnNewSceneHandler(IScene scene)
{
}
and that could then call the interface registration method
That is clean, doesn't push Scenes
Re: [Opensim-dev] Comms Manager
Well, here goes MW wrote: I'm not actually bothered about the interface per se. What I require is to be able to dynamically load generic modules that no where in that module does it know about IScene/Scene. That can be done with what you suggested I actually see your approach as complex because it demands they need to know how to register to a scene themselves when these types shouldn't need to know. The types of modules I mean are ones where they just want to register with the Core/Application and be accessed from anywhere in the application. And that is where we diverge. I believe top allow unchecked access to modules never writte to be used bby scenes, from scenes, would expose functionality to scenes that they should not have access to. It would be an internal privilege escalation, if a scene could, for instance, call a method in the region loader directly and find out about other scenes. Or unload another scene, etc. That is why I object to having those modules callable from anywhere. Some simple boilerplate code that, in the context of a grid server, would simply do nothing, but in the context of a region server would attach to scenes and expose a narrowly tailored interface there seems to be much more secure. We could even provide an abstract base class that a module may inherit from to get that functionality provided for it. But directly calling into that level of the app from scene? There be dragons! Of course this module type doesn't fit all needs, but thats what I'm saying its not right to try to find a single solution that fits all needs and turns out to be more complex than some modules require. And we shouldn't rule out such generic modules. Please see above. It can easily be done to expose an interface to Scene that is meant to be used in a Scene context and exposes only things Scene should be able to do. Now we could still do meet the above requirement with you system, but it would mean doing some automagic in a ApplicationPlugin (or whatever interface they used) loader. No. Explicit implementation in the module, or inheriting an abstract base that provides it, to reduce code duplication. As the loader would have to provide its own IServiceCore implementation, that it passed to the IServiceModules that it loaded, then it would need to as your examples show handle scene creation and register the all the IServiceModules with those. No. The modules would do that. In my example, the Region Loader is JustAnotherModule(tm). The IServiceCore (which you came up with) has no knowledge of it. The key here is that loader, the result of RequestModuleInterfaceIRegionLoader(), would be null in a grid server and not null in a region server. The remaining stuff (Region hooking) can depend on that, making the module work in a grid server context as well as a region server context, having an interface that can safely be accessed from a scene and is explicit, and avoiding access to modules that don't want to talk to scenes at all. This it does get complex, where the simply solution and the one I favour is to just have a sharedRegistry that scenes can access. That is what I wouldn't like to have. Too dangerous! The whole automagic came from me trying to find a compromise that met your ideas. I really dislike it though, but we just need to find a compromise as we both have slighly different ideas and requirements. I think my idea can serve your purpose without forcing everyone to compromise internal application security and encapsulation. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Comms Manager
Again your looking for one solution where I don't think one fits or if it does we haven't found it. I don't see RegionLoaders or anything like that using the generic interface that I'm talking about. They should be separate and as you said the scene shouldn't have access to them. But that doesn't mean we shouldn't provide the means for some modules to register with all scenes and the application without having to know about Scenes. Even with your system, the region loader could register itself with scenes if someone changed it to do so. So the same if we have some sort of RegisterWithAll method. It can be miss used but we can't stop that anyway. So I'm still for a system that allows modules that don't need to know about Scenes. Again some modules will be like you said and want to have complete control of what scenes they register with, but some won't. --- 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, 6:00 PM Well, here goes MW wrote: I'm not actually bothered about the interface per se. What I require is to be able to dynamically load generic modules that no where in that module does it know about IScene/Scene. That can be done with what you suggested I actually see your approach as complex because it demands they need to know how to register to a scene themselves when these types shouldn't need to know. The types of modules I mean are ones where they just want to register with the Core/Application and be accessed from anywhere in the application. And that is where we diverge. I believe top allow unchecked access to modules never writte to be used bby scenes, from scenes, would expose functionality to scenes that they should not have access to. It would be an internal privilege escalation, if a scene could, for instance, call a method in the region loader directly and find out about other scenes. Or unload another scene, etc. That is why I object to having those modules callable from anywhere. Some simple boilerplate code that, in the context of a grid server, would simply do nothing, but in the context of a region server would attach to scenes and expose a narrowly tailored interface there seems to be much more secure. We could even provide an abstract base class that a module may inherit from to get that functionality provided for it. But directly calling into that level of the app from scene? There be dragons! Of course this module type doesn't fit all needs, but thats what I'm saying its not right to try to find a single solution that fits all needs and turns out to be more complex than some modules require. And we shouldn't rule out such generic modules. Please see above. It can easily be done to expose an interface to Scene that is meant to be used in a Scene context and exposes only things Scene should be able to do. Now we could still do meet the above requirement with you system, but it would mean doing some automagic in a ApplicationPlugin (or whatever interface they used) loader. No. Explicit implementation in the module, or inheriting an abstract base that provides it, to reduce code duplication. As the loader would have to provide its own IServiceCore implementation, that it passed to the IServiceModules that it loaded, then it would need to as your examples show handle scene creation and register the all the IServiceModules with those. No. The modules would do that. In my example, the Region Loader is JustAnotherModule(tm). The IServiceCore (which you came up with) has no knowledge of it. The key here is that loader, the result of RequestModuleInterfaceIRegionLoader(), would be null in a grid server and not null in a region server. The remaining stuff (Region hooking) can depend on that, making the module work in a grid server context as well as a region server context, having an interface that can safely be accessed from a scene and is explicit, and avoiding access to modules that don't want to talk to scenes at all. This it does get complex, where the simply solution and the one I favour is to just have a sharedRegistry that scenes can access. That is what I wouldn't like to have. Too dangerous! The whole automagic came from me trying to find a compromise that met your ideas. I really dislike it though, but we just need to find a compromise as we both have slighly different ideas and requirements. I think my idea can serve your purpose without forcing everyone to compromise internal application security and encapsulation. Melanie ___ 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
Re: [Opensim-dev] Comms Manager
A couple of issues/questions are: How would a Region/ServiceModule say what interface it wanted to register, it might implement a couple but only want to register one, or it might want to register its class type. And I'm taking it we would still have the ApplicationPlugin that could register with what regions it wanted, so would still need the Scene.RegisterModule() interface for them. --- On Thu, 26/2/09, Justin Clark-Casey jjusti...@googlemail.com wrote: From: Justin Clark-Casey jjusti...@googlemail.com Subject: Re: [Opensim-dev] Comms Manager To: opensim-dev@lists.berlios.de Date: Thursday, 26 February, 2009, 7:07 PM MW wrote: I'm not actually bothered about the interface per se. What I require is to be able to dynamically load generic modules that no where in that module does it know about IScene/Scene. I actually see your approach as complex because it demands they need to know how to register to a scene themselves when these types shouldn't need to know. The types of modules I mean are ones where they just want to register with the Core/Application and be accessed from anywhere in the application. Of course this module type doesn't fit all needs, but thats what I'm saying its not right to try to find a single solution that fits all needs and turns out to be more complex than some modules require. And we shouldn't rule out such generic modules. Now we could still do meet the above requirement with you system, but it would mean doing some automagic in a ApplicationPlugin (or whatever interface they used) loader. As the loader would have to provide its own IServiceCore implementation, that it passed to the IServiceModules that it loaded, then it would need to as your examples show handle scene creation and register the all the IServiceModules with those. This it does get complex, where the simply solution and the one I favour is to just have a sharedRegistry that scenes can access. The whole automagic came from me trying to find a compromise that met your ideas. I really dislike it though, but we just need to find a compromise as we both have slighly different ideas and requirements. Thats why I would like to hear from other people. Okay, it seems to me that the chief problem now is that MW would like to exposed service module methods to regions without having to put any IScene methods in the module code, allowing it to be used for both the region server and grid servers. This is possible if all the service methods are exposed to the region. However, Melanie doesn't like this because it will expose some methods that regions should arguably not be able to get at (such as IInventoryService.CreateNewUserInventory()). I would tend to think that we shouldn't expose such service methods to regions. Neither side likes automagic by the core code, but I think a little bit of it will help here. Instead of having methods such as void RegisterInterfaceToAllRegistriesT(T iface); we instead annotate service modules with [RegionModule] and region interfaces with [RegionInterface]. Grid modules which can also provide region services are annotated in this way. When the core code goes to load them, the [RegionInterface] tagged interfaces are automatically registered with the region registry. This replaces RegisterModuleInterface(). It also requires that IServiceModule and IRegionModule are collapsed together, by removing the IScene references in IRegionModule. Instead, these are passed in via the OnNewScene() event talked about earlier. In this way, service/application modules that aren't interested in scenes don't need to do any extra work apart from tagging the module/interfaces appropriately, avoiding the boilerplate of separately registering the interface to each region. The regions still don't have access to inter-service/non-region interfaces. This does require a separate service registry hidden from the Region/Scene so that services can communicate among themselves (e.g. the user service needs to call the inventory service to create new user inventories). There would be 2 registries in total. Please excuse me if I haven't fully grokked all the previous posts on this thread. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Comms Manager
MW wrote:
A couple of issues/questions are:
How would a Region/ServiceModule say what interface it wanted to
register, it might implement a couple but only want to register one, or
it might want to register its class type.
:( Yeah, you're right - for some reason I forgot that you have to explicitly
name the interface when you make the
RegisterModuleInterface() call. e.g.
RegisterModuleInterfaceIHappyModuleMethods(this);
I don't believe this can be achieved via reflection.
However, I think you could still indicate which interfaces should be exposed to
the region by adding attributes to them.
For example, in Initialise() you could do something like
RegistryManager.RegisterModuleInterfaceIHappyModuleMethods(this);
And annotate the interfaces with something like
[ServiceInterface]
public interface IHappyModuleMethods { ... }
In a region server, the interface would be added to the region registry. In a
grid server, the interface would be added
to the grid registry.
If one wanted a non-region 'application only' interface in the region server,
then one could perhaps also add
[ApplicationInterface]
public interface IEvilApplicationMethods { ... }
with
RegistryManager.RegisterModuleInterfaceIEvilApplicationMethods(this);
In a region service this could be added only to the application registry and
not the region registry. In a grid service
it would still be added to the single grid registry.
This is getting messy though and I'm not sure how much it buys you over simply
indicating the 'type' (service or
application) when you initially register it. Mostly this all becomes a
refinement of your earlier
void RegisterInterfaceToAllRegistriesT(T iface);
And I'm taking it we would still have the ApplicationPlugin that could
register with what regions it wanted, so would still need the
Scene.RegisterModule() interface for them.
--- On *Thu, 26/2/09, Justin Clark-Casey /jjusti...@googlemail.com/*
wrote:
From: Justin Clark-Casey jjusti...@googlemail.com
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 7:07 PM
MW wrote:
I'm not actually bothered about the interface per se. What I require
is
to be able to dynamically load generic modules that no where in that
module does it know about IScene/Scene.
I actually see your approach as complex because it demands they need to
know how to register to a scene themselves when these types shouldn't
need to know. The types of modules I mean are ones where they just want
to register with the Core/Application and be accessed from anywhere in
the application.
Of course this module type doesn't fit all needs, but thats what
I'm
saying its not right to try to find a single solution that fits all
needs and turns out to be more complex than some modules require. And
we
shouldn't rule out such generic modules.
Now we could still do meet the above requirement with you system, but
it
would mean doing some automagic in a ApplicationPlugin (or whatever
interface they used) loader.
As the loader would have to provide its own IServiceCore
implementation,
that it passed to the IServiceModules that it loaded, then it would
need
to as your examples show handle scene creation and register the all the
IServiceModules with those.
This it does get complex, where the simply solution and the one I
favour
is to just have a sharedRegistry that scenes can access.
The whole
automagic came from me trying to find a compromise that met your ideas.
I really dislike it though, but we just need to find a compromise as we
both have slighly different ideas and requirements.
Thats why I would like to hear from other people.
Okay, it seems to me that the chief problem now is that MW would like to
exposed service module methods to regions
without having to put any IScene methods in the module code, allowing it
to be
used for both the region server and grid
servers.
This is possible if all the service methods are exposed to the region.
However, Melanie doesn't like this because it
will expose some methods that regions should arguably not be able to get
at
(such as
IInventoryService.CreateNewUserInventory()).
I would tend to think that we shouldn't expose such service methods to
regions.
Neither side likes automagic by the
core code, but I think a little bit of it
will help here. Instead of having methods
such as
void RegisterInterfaceToAllRegistriesT(T iface);
we instead annotate service modules with [RegionModule] and region
interfaces
with [RegionInterface]. Grid modules
which can also provide region services
Re: [Opensim-dev] Comms Manager
On that subject I keep coming back to the idea that there should be two
register Interface methods.
And my lastest idea is about having the concept of Primary Registry and
Secondary Registry as a concept in the IServiceCore interface.
The primary registry will be the protected Application registry, that
only privileged components should have access to. And the secondary
Registry is lower security.
Then a IServiceModule can decide if it wants to register with the
secondary Registry at all. A module could also register different
interfaces to each Registry. So say a cut down interface to the
Secondary Registry.
In the context of a ServiceModule being loaded into a Grid server, it
won't make any difference as (currently) they won't have any secondary
Registries, so those methods will just be stubbs.
But in the context of it being loaded into the region server. The
loader will handle the automagic of adding all modules, that have
registered with the secondary Registry, to the Scenes.
So we would have two register methods like:
void RegisterPrimaryInterfaceT(T iface);
void RegisterSecondaryInterfaceT(T iface);
--- 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, 8:50 PM
Yes, Sounds good. It will, of course, expose _all_ service modules to all
Scenes. If that is wanted in the long run is another question.
But, +1
Melanie
MW wrote:
Well I think the compromise we basically agreed on is that we go with
IApplicationPlugins being able to register to the ApplicationRegistry and also
(via OnRegionCreated events) to the scenes.
And then for the service modules, we can have a loader that itself is a
IApplicationPlugin that loads the service modules (IServiceModule) and does the
auto registering for them. This way at least this automagic is out of the core
opensimbase (etc).
--- 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, 8:37 PM
Well, if it gets that evil, then we might as well stick with plan A. As
long as this All region registration is in that specific application
module, and not global.
I believe modules written to load into region servers should also handle
this explicitly.
Melanie
Justin Clark-Casey wrote:
MW wrote:
A couple of issues/questions are:
How would a Region/ServiceModule say what interface it wanted to
register, it might implement a couple but only want to register one,
or
it might want to register its class type.
:( Yeah, you're right - for some reason I forgot that you have to
explicitly name the interface when you make the
RegisterModuleInterface() call. e.g.
RegisterModuleInterfaceIHappyModuleMethods(this);
I don't believe this can be achieved via reflection.
However, I think you could still indicate which interfaces should be
exposed to the region by adding attributes to them.
For example, in Initialise() you could do something like
RegistryManager.RegisterModuleInterfaceIHappyModuleMethods(this);
And annotate the interfaces with something like
[ServiceInterface]
public interface IHappyModuleMethods { ... }
In a region server, the interface would be added to the region
registry.
In a grid server, the interface would be added
to the grid registry.
If one wanted a non-region 'application only' interface in the
region server, then one could perhaps also add
[ApplicationInterface]
public interface IEvilApplicationMethods { ... }
with
RegistryManager.RegisterModuleInterfaceIEvilApplicationMethods(this);
In a region service this could be added only to the application
registry
and not the region registry. In a grid service
it would still be added to the single grid registry.
This is getting messy though and I'm not sure how much it buys you
over simply indicating the 'type' (service or
application) when you initially register it. Mostly this all becomes
a
refinement of your earlier
void RegisterInterfaceToAllRegistriesT(T iface);
And I'm taking it we would still have the ApplicationPlugin
that
could
register with what regions it wanted, so would still need the
Scene.RegisterModule() interface for them.
--- On *Thu, 26/2/09, Justin Clark-Casey
/jjusti...@googlemail.com/*
wrote:
From: Justin Clark-Casey jjusti...@googlemail.com
Subject: Re: [Opensim-dev] Comms Manager
To: opensim-dev@lists.berlios.de
Date: Thursday, 26 February, 2009, 7:07 PM
MW wrote:
I'm not actually bothered about the interface per se.
What I require
is to be able to dynamically load generic modules
that no where
in that
module does it know about IScene/Scene.
I actually see your approach as complex because
Re: [Opensim-dev] Comms Manager
Or a slightly different approach would be to add a security level as a a param
of the RegisterInterface method.
So that a module could register multiple interface with different security
levels. Its then up to the application/loader which componets get access to
which interfaces (or in our implementation which registries those interfaces
would be added to)
Anyway these are just ideas at the moment. The base system we have agreed to
(unless anyone else objects) is the IApplicationPlugin being able to register
to the ApplicationRegistry and to Scenes as it choices. Then having a
ApplicationPlugin that is a loader of IService modules. So these ideas are just
about how that loader handles things.
--- 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, 11:17 PM
On that subject I keep coming back to the idea that there should be two
register Interface methods.
And my lastest idea is about having the concept of Primary Registry and
Secondary Registry as a concept in the IServiceCore interface.
The primary registry will be the protected Application registry, that
only privileged components should have access to. And the secondary
Registry is lower security.
Then a IServiceModule can decide if it wants to register with the
secondary Registry at all. A module could also register different
interfaces to each Registry. So say a cut down interface to the
Secondary Registry.
In the context of a ServiceModule being loaded into a Grid server, it
won't make any difference as (currently) they won't have any secondary
Registries, so those methods will just be stubbs.
But in the context of it being loaded into the region server. The
loader will handle the automagic of adding all modules, that have
registered with the secondary Registry, to the Scenes.
So we would have two register methods like:
void RegisterPrimaryInterfaceT(T iface);
void RegisterSecondaryInterfaceT(T iface);
--- 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, 8:50 PM
Yes, Sounds good. It will, of course, expose _all_ service modules to all
Scenes. If that is wanted in the long run is another question.
But, +1
Melanie
MW wrote:
Well I think the compromise we basically agreed on is that we go with
IApplicationPlugins being able to register to the ApplicationRegistry and also
(via OnRegionCreated events) to the scenes.
And then for the service modules, we can have a loader that itself is a
IApplicationPlugin that loads the service
modules (IServiceModule) and does the
auto registering for them. This way at least this automagic is out of the core
opensimbase (etc).
--- 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, 8:37 PM
Well, if it gets that evil, then we might as well stick with plan A. As
long as this All region registration is in that specific application
module, and not global.
I believe modules written to load into region servers should also handle
this explicitly.
Melanie
Justin Clark-Casey wrote:
MW wrote:
A couple of issues/questions are:
How would a Region/ServiceModule say what interface it wanted to
register, it might implement a
couple but only want to register one,
or
it might want to register its class type.
:( Yeah, you're right - for some reason I forgot that you have to
explicitly name the interface when you make the
RegisterModuleInterface() call. e.g.
RegisterModuleInterfaceIHappyModuleMethods(this);
I don't believe this can be achieved via reflection.
However, I think you could still indicate which interfaces should be
exposed to the region by adding attributes to them.
For example, in Initialise() you could do something like
RegistryManager.RegisterModuleInterfaceIHappyModuleMethods(this);
And annotate the interfaces with something like
[ServiceInterface]
public interface IHappyModuleMethods { ...
}
In a region server, the interface would be added to the region
registry.
In a grid server, the interface would be added
to the grid registry.
If one wanted a non-region 'application only' interface in the
region server, then one could perhaps also add
[ApplicationInterface]
public interface IEvilApplicationMethods { ... }
with
RegistryManager.RegisterModuleInterfaceIEvilApplicationMethods(this);
In a region service this could be added only to the application
registry
and not the region registry. In a grid service
it would still be added to the single grid registry.
This is getting messy though and I'm not sure how much it buys you
over simply
Re: [Opensim-dev] Comms Manager
Why is it that you want to have some fixed, hardcoded behavior
instead of leaving it to the module?
I thought what we ended up with was fine and agreeable to all, and
now here you come again with region modules/regions accessing the
core directly. I think that is a BadIdea(tm) to allow calls from
regions into base directly.
Melanie
MW wrote:
Or a slightly different approach would be to add a security level as a a
param of the RegisterInterface method.
So that a module could register multiple interface with different security
levels. Its then up to the application/loader which componets get access to
which interfaces (or in our implementation which registries those interfaces
would be added to)
Anyway these are just ideas at the moment. The base system we have agreed to
(unless anyone else objects) is the IApplicationPlugin being able to register
to the ApplicationRegistry and to Scenes as it choices. Then having a
ApplicationPlugin that is a loader of IService modules. So these ideas are
just about how that loader handles things.
--- 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, 11:17 PM
On that subject I keep coming back to the idea that there should be two
register Interface methods.
And my lastest idea is about having the concept of Primary Registry and
Secondary Registry as a concept in the IServiceCore interface.
The primary registry will be the protected Application registry, that
only privileged components should have access to. And the secondary
Registry is lower security.
Then a IServiceModule can decide if it wants to register with the
secondary Registry at all. A module could also register different
interfaces to each Registry. So say a cut down interface to the
Secondary Registry.
In the context of a ServiceModule being loaded into a Grid server, it
won't make any difference as (currently) they won't have any secondary
Registries, so those methods will just be stubbs.
But in the context of it being loaded into the region server. The
loader will handle the automagic of adding all modules, that have
registered with the secondary Registry, to the Scenes.
So we would have two register methods like:
void RegisterPrimaryInterfaceT(T iface);
void RegisterSecondaryInterfaceT(T iface);
--- 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, 8:50 PM
Yes, Sounds good. It will, of course, expose _all_ service modules to all
Scenes. If that is wanted in the long run is another question.
But, +1
Melanie
MW wrote:
Well I think the compromise we basically agreed on is that we go with
IApplicationPlugins being able to register to the ApplicationRegistry and also
(via OnRegionCreated events) to the scenes.
And then for the service modules, we can have a loader that itself is a
IApplicationPlugin that loads the service
modules (IServiceModule) and does the
auto registering for them. This way at least this automagic is out of the core
opensimbase (etc).
--- 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, 8:37 PM
Well, if it gets that evil, then we might as well stick with plan A. As
long as this All region registration is in that specific application
module, and not global.
I believe modules written to load into region servers should also handle
this explicitly.
Melanie
Justin Clark-Casey wrote:
MW wrote:
A couple of issues/questions are:
How would a Region/ServiceModule say what interface it wanted to
register, it might implement a
couple but only want to register one,
or
it might want to register its class type.
:( Yeah, you're right - for some reason I forgot that you have to
explicitly name the interface when you make the
RegisterModuleInterface() call. e.g.
RegisterModuleInterfaceIHappyModuleMethods(this);
I don't believe this can be achieved via reflection.
However, I think you could still indicate which interfaces should be
exposed to the region by adding attributes to them.
For example, in Initialise() you could do something like
RegistryManager.RegisterModuleInterfaceIHappyModuleMethods(this);
And annotate the interfaces with something like
[ServiceInterface]
public interface IHappyModuleMethods { ...
}
In a region server, the interface would be added to the region
registry.
In a grid server, the interface would be added
to the grid registry.
If one wanted a non-region 'application only' interface in the
region server, then one could
Re: [Opensim-dev] Comms Manager
Did you actually read what I said? I said the base idea of ApplicationPlugins being able to register with the ApplicationRegistry and with scenes as they wish is what we were going with. But we would then have a Plugin that was a loader of IServiceModules. The ideas I was throwing out there were how that plugin handles things. As was actually in answer to your comment about do we want all ServiceModules registered with the regions. So I was thinking of a method that allows ServiceModules to decide which they actually register to. Again I never mentioned the Regions/Region modules accessing the core at all. I said the Service modules would be able to use diferent Registry methods to say if they should be added to the Scene Registries or not. I'd say thats a step away from a hardcode behavior of having all Service Mdoules registered with the Scenes. Which we agreed earlier. No matter what you think, I think there should be a ServiceModule system that doesn't need to know about Scenes. Now we have agreed that this will be bult on top of the IApplicationPlugin system. So now I'm just talking about how the automagic will work. --- 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, 11:51 PM Why is it that you want to have some fixed, hardcoded behavior instead of leaving it to the module? I thought what we ended up with was fine and agreeable to all, and now here you come again with region modules/regions accessing the core directly. I think that is a BadIdea(tm) to allow calls from regions into base directly. Melanie MW wrote: Or a slightly different approach would be to add a security level as a a param of the RegisterInterface method. So that a module could register multiple interface with different security levels. Its then up to the application/loader which componets get access to which interfaces (or in our implementation which registries those interfaces would be added to) Anyway these are just ideas at the moment. The base system we have agreed to (unless anyone else objects) is the IApplicationPlugin being able to register to the ApplicationRegistry and to Scenes as it choices. Then having a ApplicationPlugin that is a loader of IService modules. So these ideas are just about how that loader handles things. --- 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, 11:17 PM On that subject I keep coming back to the idea that there should be two register Interface methods. And my lastest idea is about having the concept of Primary Registry and Secondary Registry as a concept in the IServiceCore interface. The primary registry will be the protected Application registry, that only privileged components should have access to. And the secondary Registry is lower security. Then a IServiceModule can decide if it wants to register with the secondary Registry at all. A module could also register different interfaces to each Registry. So say a cut down interface to the Secondary Registry. In the context of a ServiceModule being loaded into a Grid server, it won't make any difference as (currently) they won't have any secondary Registries, so those methods will just be stubbs. But in the context of it being loaded into the region server. The loader will handle the automagic of adding all modules, that have registered with the secondary Registry, to the Scenes. So we would have two register methods like: void RegisterPrimaryInterfaceT(T iface); void RegisterSecondaryInterfaceT(T iface); --- 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, 8:50 PM Yes, Sounds good. It will, of course, expose _all_ service modules to all Scenes. If that is wanted in the long run is another question. But, +1 Melanie MW wrote: Well I think the compromise we basically agreed on is that we go with IApplicationPlugins being able to register to the ApplicationRegistry and also (via OnRegionCreated events) to the scenes. And then for the service modules, we can have a loader that itself is a IApplicationPlugin that loads the service modules (IServiceModule) and does the auto registering for them. This way at least this automagic is out of the core opensimbase (etc). --- 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, 8:37 PM Well, if it gets that evil, then we might as well stick with plan
Re: [Opensim-dev] Comms Manager
Hi, MW wrote: Again I never mentioned the Regions/Region modules accessing the core at all. I said the Service modules would be able to use diferent Registry methods to say if they should be added to the Scene Registries or not. I'd say thats a step away from a hardcode behavior of having all Service Mdoules registered with the Scenes. Which we agreed earlier. No matter what you think, I think there should be a ServiceModule system that doesn't need to know about Scenes. Now we have agreed that this will be bult on top of the IApplicationPlugin system. So now I'm just talking about how the automagic will work. Yes, I misunderstood you there, when you mentioned two registries, the concept of one application, one region accessible that was discussed earlier came to mind and i didn't read it in enough depth to see this was distinct from it. I'm sorry, and of course I have no objections here. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Comms Manager
Wonderful, marvellous, exactly what I always dreamed and prayed about. You are
my hero et c et c.
That gridservice registry will, in effect, be somehting like the 'shared
module' registry we've discussed before, so +1 on that fo sho.
On the topic of which plugins, and what specific class if many defined in same
assembly, I refer to an earlier post, where I said:
I don't know how mono.addins does it, but in the rest of the .net world, you
specify assembly and class separated by ', ' thus:
plugin=System.Framework.dll, System.Framework.PluginClass
So that bit should be fairly simple, given mono addins handles it, which I
would be surprised and disappointed if it didn't.
Best regards,
Stefan Andersson
Tribal Media AB
Date: Wed, 25 Feb 2009 20:43:10 +
From: michaelwr...@yahoo.co.uk
To: opensim-dev@lists.berlios.de
Subject: [Opensim-dev] Comms Manager
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 GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(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 TryGetT(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
Re: [Opensim-dev] Comms Manager
Hi,
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 GetT();
void RegisterInterfaceT(T iface);
bool TryGetT(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 TryGetT(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
