[Opensim-dev] Comms Manager
Melanie
melanie at t-data.com
Thu Feb 26 14:40:52 UTC 2009
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 <michaelwri22 at yahoo.co.uk> wrote:
> From: MW <michaelwri22 at yahoo.co.uk>
> Subject: Re: [Opensim-dev] Comms Manager
> To: opensim-dev at 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 <melanie at t-data.com> wrote:
> From: Melanie <melanie at t-data.com>
> Subject: Re:
> [Opensim-dev] Comms Manager
> To: michaelwri22 at yahoo.co.uk, opensim-dev at 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 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 <melanie at t-data.com> wrote:
>> From: Melanie <melanie at t-data.com>
>> Subject: Re: [Opensim-dev] Comms Manager
>> To: michaelwri22 at yahoo.co.uk, opensim-dev at 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()
>>>
>>> {
>>>
>>> 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 <melanie at t-data.com> wrote:
>>> From: Melanie <melanie at t-data.com>
>>> Subject: Re: [Opensim-dev] Comms Manager
>>> To: michaelwri22 at yahoo.co.uk, opensim-dev at 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 <melanie at t-data.com> wrote:
>>>> From: Melanie <melanie at t-data.com>
>>>> Subject: Re: [Opensim-dev] Comms Manager
>>>> To: opensim-dev at 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 +0000
>>>>>> From: melanie at t-data.com
>>>>>> To: opensim-dev at 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 at lists.berlios.de
>>>>>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>>>
>
>>>
>>>
>>>
>>>
> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing
> list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list