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 <[email protected]> wrote: > From: MW <[email protected]> > Subject: Re: [Opensim-dev] Comms Manager > To: [email protected] > 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 <[email protected]> wrote: > From: Melanie <[email protected]> > Subject: Re: > [Opensim-dev] Comms Manager > To: [email protected], [email protected] > 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 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 > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
