[Opensim-dev] Comms Manager
Melanie
melanie at t-data.com
Thu Feb 26 17:28:09 UTC 2009
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 RegisterModuleInterface<T>(T module);
void UnregisterModuleInterface<T>();
T RequesModuleInterface<T>();
...
}
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.RequestModuleInterface<IRegionLoader>();
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 <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, 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.RequestModuleInterface<IRegionLoader>();
>
> 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 Get<T>();
>> void RegisterInterface<T>(T iface);
>> void RegisterInterfaceToAllRegistries<T>(T iface);
>> bool TryGet<T>(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 <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, 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 <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
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> 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