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.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 <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
>>> {
>>> 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 <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()
>>>>
>>>> {
>>>>
>>>> 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 <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 +0000
>>>>>>> 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
>>>>
>>>>
>>>>
>>
>>>>
>>>>
>>
------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
