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 <[email protected]> wrote: > From: MW <[email protected]> > Subject: Re: [Opensim-dev] Comms Manager > To: [email protected] > 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 Get<T>(); > void RegisterInterface<T>(T iface); > bool TryGet<T>(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 <[email protected]> wrote: > From: Melanie <[email protected]> > Subject: Re: [Opensim-dev] Comms Manager > To: [email protected], [email protected] > 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() >> >> { >> >> PluginLoader<IApplicationPlugin> loader = >> >> new PluginLoader<IApplicationPlugin>(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) >> >> >> >> { >> >> >> >> PluginLoader<IGridServiceModule> loader = >> >> >> >> new PluginLoader<IGridServiceModule>(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 <[email protected]> wrote: >> From: Melanie <[email protected]> >> Subject: Re: [Opensim-dev] Comms Manager >> To: [email protected], [email protected] >> 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 <[email protected]> wrote: >>> From: Melanie <[email protected]> >>> Subject: Re: [Opensim-dev] Comms Manager >>> To: [email protected] >>> 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 +0000 >>>>> From: [email protected] >>>>> To: [email protected] >>>>> 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 >>>> [email protected] >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> > https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >>> >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> > https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
