<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Well I still want to be able to have a module that implements a very simple generic interface something like: <br><br> public interface IGridServiceModule<br> {<br> void Close();<br> void Initialise(IGridServiceCore core);<br> void PostInitialise();<br> }<br><br>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.<br><br>--- On <b>Thu, 26/2/09, Melanie <i><melanie@t-data.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Melanie <melanie@t-data.com><br>Subject: Re: [Opensim-dev] Comms Manager<br>To: michaelwri22@yahoo.co.uk, opensim-dev@lists.berlios.de<br>Date: Thursday, 26 February, 2009, 5:05 PM<br><br><pre>In my (much simpler) design, the IScene won't even need to be on the<br>interface. All that is needed is for the core (Scene loader) to provide the<br>OnNewScene and OnRemoveScene events. In my example, I placed those on the<br>interface, that was actually not needed at all.<br><br>I do believe that the registration to scenes should be done by a piece of<br>boilerplate code int he module itself, and not automagically. The automagical<br>registration leaves no room to expose a _different_ interface to the scene from<br>what is
exposed to the application. Since many application level methods would<br>be useless to Scenes and may be harmful, and vice versa, the two-interface<br>approach I outlined seems cleaner.<br><br>In the simplest case:<br><br>MyApplicationModule : IApplicationPlugin<br>{<br>IApplicationPlugin members<br>....<br>}<br><br>Nothing special there, clean and simple<br><br>Then, if we want to be notified about scenes to register to them, grab the<br>region loader interface:<br><br>IRegionLoader loader =<br>application.RequestModuleInterface<IRegionLoader>();<br><br>and _then_ hook from there:<br><br>loader.OnNewScene += OnNewSceneHandler<br><br>Which doesn't have to be on any interface.<br>It would just be a class member:<br><br>private void OnNewSceneHandler(IScene scene)<br>{<br>}<br><br>and that could then call the interface registration method<br><br>That is clean, doesn't push Scenes into modules that don't want them,<br>allows exposing interfaces to
Scenes with a minimum of boilerplate, and has no<br>automagic that is hard to understand or brittle.<br><br>Melanie<br><br><br>MW wrote:<br>> I still think we should have a SharedRegistry that all Scenes have access<br>to. Some of the current shared RegionModules could move to using it as well. And<br>I know some of the other devs want one to; Adam and Stefan were talking about<br>one in IRC the other day.<br>> <br>> But if we all agree that we actually don't want one of them. Then a<br>possible compromise might be adding a extra RegisterToAllRegistries method to<br>the core Global registry interface so something like:<br>> <br>> public interface IGridServiceCore<br>> {<br>> T Get<T>();<br>> void RegisterInterface<T>(T iface);<br>> void RegisterInterfaceToAllRegistries<T>(T iface);<br>> bool TryGet<T>(out T iface);<br>> }<br>> <br>> This would add
the interface to a list, that then is "copied" to<br>each region that starts up, so a kind of auto registration. Without the modules<br>having to be given scene references if the interface type they are using<br>doesn't support that. <br>> So all we would be doing is making OpenSimBase implement that interface<br>and provide the support for the "auto registration" to Scenes with<br>RegisterInterfaceToAllRegistries. Any module/plugin using RegisterInterface<br>would only register with the Global/Application registry that wouldn't be<br>accessable from regions. Of course they could then manually register themselves<br>with the regions.<br>> <br>> I just really dislike trying Scene/IScene into all the plugin interfaces.<br>I'm fine with plugins being able to access them via a IApplicationPlugin if<br>thats the way the plugin creator did things. But I also want a more generic<br>module type that can still offer services to regions/scenes. Most
likely using<br>the plugin loader approach I mentioned earlier. If this extra plugin loading was<br>done by a ApplicationPlugin then anyone who didn't want to support those<br>types could easily remove that loader.<br>> <br>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com> wrote:<br>> From: Melanie <melanie@t-data.com><br>> Subject: Re: [Opensim-dev] Comms Manager<br>> To: michaelwri22@yahoo.co.uk, opensim-dev@lists.berlios.de<br>> Date: Thursday, 26 February, 2009, 2:40 PM<br>> <br>> I think that would introduce a layer of complexity in core, where i think<br>that<br>> complexity (e.g. registering to scenes) s better off distributed inside<br>the<br>> modules that actually need it. Keep it simple. I believe my approach is<br>what<br>> will work with the least amount of core code, and provide the greatest<br>> flexibility.<br>> <br>> Melanie<br>> <br>> MW wrote:<br>>> I know I said we
should wait for other people to give some input, but<br>just<br>> one last suggestion.<br>>> <br>>> Maybe we should have three registeries. A ApplicationServiceRegistry<br>that<br>> is only accessable from the application level), A SharedServiceRegistry<br>that is<br>> accessable from the application and all scenes/regions. And then the<br>current<br>> Registry in Scene.<br>>> <br>>> Then its upto the modules/components/plugins to which registries they<br>want<br>> to register.<br>>> <br>>> And certain plugin types might only get references allowing them to<br>> register to certain registeries. <br>>> --- On Thu, 26/2/09, MW <michaelwri22@yahoo.co.uk> wrote:<br>>> From: MW <michaelwri22@yahoo.co.uk><br>>> Subject: Re: [Opensim-dev] Comms Manager<br>>> To: opensim-dev@lists.berlios.de<br>>> Date: Thursday, 26 February, 2009, 1:48 PM<br>>> <br>>>
Well actually my suggestion of supporting multiple plugin interfaces<br>> allowed both approaches and left everything up to the module creator. <br>>> But I think we should wait for input from others now as we aren't<br>> really getting anywhere on the fine details. I think we have the basis of<br>a<br>> system just need to get other peope's input so we can work out those<br>small<br>> details. Like the main one being should the global registry be accessable<br>from<br>> regions. And if we decide it shouldn't, is it okay for it be in the<br>short<br>> term so we can refactor comms manager easiest. ie comms manager becomes<br>the<br>> global registry for now. <br>>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com> wrote:<br>>> From: Melanie <melanie@t-data.com><br>>> Subject: Re:<br>>> [Opensim-dev] Comms Manager<br>>> To: michaelwri22@yahoo.co.uk,
opensim-dev@lists.berlios.de<br>>> Date: Thursday, 26 February, 2009, 1:36 PM<br>>> <br>>> If you want to be more flexible, then my approach is better. In your<br>> model, a global module has not way to _prevent_ being accessed by Scene.<br>>> <br>>> I believe Scene has no business holding a ref to the application, or<br>> accessing the global registry.<br>>> <br>>> In my design, each module has the power to decide whether it wants to<br>be<br>> accessible from Scene and what methods it exposes to it. Your method<br>reduces<br>> that duality into a single interface and makes all scenes be able to<br>access all<br>> methods on all interfaces. That leaves no room for isolation, even if a<br>module<br>> writer would want it.<br>>> <br>>> I believe the modules _should_ indeed register with each scene in a<br>> callback, and that would actually let them register only to
specific<br>scenes if<br>> they wanted to. More flexibility<br>>> yet.<br>>> <br>>> Melanie<br>>> <br>>> MW wrote:<br>>>> Hmm, I never suggested anything that would mean one scene be able<br>to<br>>> directly access another.<br>>>> <br>>>> I see the GlobalRegistry as a very basic interface something like:<br>>>> <br>>>> public interface IGridServiceCore<br>>>> {<br>>>> T Get<T>();<br>>>> void RegisterInterface<T>(T iface);<br>>>> bool TryGet<T>(out T iface);<br>>>> }<br>>>> <br>>>> [Which would be in OpenSim.Framework or wherever]<br>>>> <br>>>> So if we did want a Scene to be able to access it, all it would<br>need<br>> on<br>>> creation is pass a IGridServiceCore reference in its parameters. So it<br>>> doesn't actually
change anything compared to how things are now<br>with<br>> the<br>>> shared modules.<br>>>> <br>>>> I just am still not sure that GlobalServices should have to<br>> indivudally<br>>> register with the Scenes even if they want to provide services to<br>region<br>>> modules. I see the<br>>> module that handled User server comms as a global service but<br>>> don't think it should have to register with all regions. I'm<br>more<br>> in<br>>> mind that it should just register with the global registry and then<br>region<br>>> modules than access that.<br>>>> <br>>>> And yes nothing I have suggested stops a ApplicationModule and a<br>>> RegionModule from sharing a dll, and the ApplicationModule starts up<br>and<br>>> registers the RegionModule or whatever. I just don't think its the<br>> solution<br>>> for everything. So am trying to think of way of
being more flexible.<br>>>> <br>>>> <br>>>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com> wrote:<br>>>> From: Melanie <melanie@t-data.com><br>>>> Subject: Re: [Opensim-dev] Comms Manager<br>>>> To: michaelwri22@yahoo.co.uk, opensim-dev@lists.berlios.de<br>>>> Date: Thursday, 26 February, 2009, 1:14 PM<br>>>> <br>>>> Hi,<br>>>> <br>>>> one of the paradigms is that no Scene should directly access<br>another<br>>> <br>>>> Scene.<br>>>> <br>>>> Therefore, providing a clear path to the global registry from the<br>DLL<br>> Scene is in would break that isolation.<br>>>> <br>>>> Really, global modules that want/need to be accessed from Scene<br>can<br>> register an interface there.<br>>>> Also, processing will probably need to be broken up into a part<br>that<br>> has the Scene
type and a part that doesn't.<br>>>> <br>>>> This is where I think a global module and a region module as well<br>as<br>> the interfaces used between them can share a dll.<br>>>> <br>>>> The global module would register that interface on the region, and<br>the<br>> region modules uses it.<br>>>> <br>>>> That is much cleaner.<br>>>> <br>>>> Melanie<br>>>> <br>>>> MW wrote:<br>>>>> Well I hadn't really thought out all the details but what<br>I<br>> meant<br>>> is<br>>>> we<br>>>>> can have a IApplicationPlugin that can load other plugin types<br>> itself.<br>>> <br>>>>> <br>>> <br>>>>> <br>>>>> <br>>>>> So if we look at the code in OpenSimBase that loads<br>>> IApplicationplugins it<br>>>> is:<br>>>>> <br>>>>>
<br>>>>> <br>>>>> protected virtual void LoadPlugins()<br>>>>> <br>>>>> {<br>>>>> <br>>>>> PluginLoader<IApplicationPlugin> loader =<br>>>>> <br>>>>> new PluginLoader<IApplicationPlugin>(new<br>>>> ApplicationPluginInitialiser(this));<br>>>>> <br>>>>> <br>>>>> <br>>>>> loader.Load("/OpenSim/Startup");<br>>>>> <br>>>>> m_plugins = loader.Plugins;<br>>>>> <br>>>>> }<br>>>>> <br>>>>> <br>>>>> <br>>>>> and the plugin initialiser is :<br>>>>> <br>>>>> <br>>>>> <br>>>>> public class ApplicationPluginInitialiser :<br>> PluginInitialiserBase<br>>>>> <br>>>>>
{<br>>>>> <br>>>>> private OpenSimBase<br>>> server;<br>>>>> <br>>>>> public ApplicationPluginInitialiser (OpenSimBase s) {<br>> server =<br>>> s;<br>>>> }<br>>>>> <br>>>>> public override void Initialise (IPlugin plugin)<br>>>>> <br>>>>> {<br>>>>> <br>>>>> IApplicationPlugin p = plugin as<br>IApplicationPlugin;<br>>>>> <br>>>>> p.Initialise (server);<br>>>>> <br>>>>> }<br>>>>> <br>>>>> }<br>>>>> <br>>>>> <br>>>>> <br>>>>> so there is no reason why inside a ApplicationPlugin we<br>can't<br>> do<br>>>> something like:<br>>>>> <br>>>>> <br>>>>> <br>>>>> public void
Initialise(OpenSimBase openSim)<br>>>>> <br>>>>> {<br>>>>> <br>>>>> LoadGridServiceModules(openSim);<br>>>>> <br>>>>> }<br>>>>> <br>>>>> <br>>>>> <br>>>>> Protected virtual void LoadGridServiceModules(OpenSimBase<br>> openSimBase)<br>>>>> <br>>>>> <br>>> <br>>>>> <br>>>>> {<br>>>>> <br>>>>> <br>>>>> <br>>>>> PluginLoader<IGridServiceModule> loader =<br>>>>> <br>>>>> <br>>>>> <br>>>>> new PluginLoader<IGridServiceModule>(new<br>>>> GridServicePluginInitialiser(openSimBase.GlobalRegistry));<br>>>>> <br>>>>> <br>>>>> <br>>>>> <br>>>>> <br>>>>>
<br>>>>> <br>>>>> loader.Load("/OpenSim/GridService");<br>>>>> <br>>>>> <br>>>>> <br>>>>> m_plugins = loader.Plugins;<br>>>>> <br>>>>> <br>>>>> <br>>>>> }<br>>>>> <br>>>>> <br>>>>> <br>>>>> public class GridServicePluginInitialiser :<br>> PluginInitialiserBase<br>>>>> <br>>>>> {<br>>>>> <br>>>>> private IGridServiceCore m_core;<br>>>>> <br>>>>> public ApplicationPluginInitialiser (IGridService<br>core) {<br>>> m_core =<br>>>> core;<br>>> }<br>>>>> <br>>>>> public override void Initialise (IPlugin plugin)<br>>>>> <br>>>>> {<br>>>>> <br>>>>>
IGridServiceModule p = plugin as<br>IGridServiceModule;<br>>>>> <br>>>>> p.Initialise (m_core);<br>>>>> <br>>>>> }<br>>>>> <br>>>>> }<br>>>>> <br>>>>> <br>>>>> <br>>>>> <br>>>>> So its then loaded the IGridServiceModules and passed them<br>only a<br>>>> reference to the GlobalRegistry (from OpenSimBase).<br>>>>> <br>>>>> <br>>>>> <br>>>>> And for plugins/modules that want to register with scenes, we<br>> could<br>>>>> either have another plugin type and loader, or just use<br>>>>> IApplicationPlugin directly for them.<br>>>>> <br>>>>> <br>>>>> <br>>>>> Of course this opens up the question if at any point the<br>>> GlobalRegistry<br>>>>> should be
accessable from scenes. If we are going to go with<br>>> the<br>>>>> approach that modules that should be accessable from scenes<br>should<br>>>>> register with them then I guess the answer is no. But I can<br>see<br>> people<br>>>>> wanting to be able to access the GlobalRegistry from Region<br>> modules<br>>> and<br>>>>> trying to do hacks so they can.<br>>>>> <br>>>>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com> wrote:<br>>>>> From: Melanie <melanie@t-data.com><br>>>>> Subject: Re: [Opensim-dev] Comms Manager<br>>>>> To: michaelwri22@yahoo.co.uk, opensim-dev@lists.berlios.de<br>>>>> Date: Thursday, 26 February, 2009, 12:50 PM<br>>>>> <br>>>>> I'd have to see that, but it sounds good.<br>>>>> <br>>>>> Can you illustrate?<br>>>>>
<br>>>>> Melanie<br>>>>> <br>>>>> MW wrote:<br>>>>>> Just a though,t but maybe we are trying to be too generic<br>in<br>>> finding a<br>>>>> single interface that meets all needs. We have a plugin<br>>> loader<br>>>> (Mono.addins)<br>>>>> that can quite easily load different plugin types. So by using<br>the<br>>>>> IApplicationPlugin system, we can have them also loading other<br>> plugin<br>>>> types. <br>>>>>> <br>>>>>> If basically we are saying that we want two different<br>>> Module/Interface<br>>>>> registeries (Global and Scene), then there is no reason that<br>as<br>> long<br>>> as<br>>>> all the<br>>>>> plugins only register interfaces with those registeries why we<br>>> can't<br>>>> have<br>>>>> the multiple plugin types.
So we have a type (and loader) that<br>is<br>> able<br>>> to<br>>>>> register event handlers so it can be informed about scenes.<br>And we<br>> a<br>>>> loader that<br>>>>> can load the modules from the Grid servers directly. <br>>>>>> <br>>>>>> The loaders would be minor things basically just using<br>>> PluginLoader to<br>>>>> load the plugins. <br>>>>>> <br>>>>>> We could say this increases<br>>> the complexity, but I actually think<br>>> by<br>>>> having<br>>>>> initialisation interfaces that are right for the task that the<br>> modules<br>>> are<br>>>> going<br>>>>> to do makes sense.<br>>>>>> <br>>>>>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com><br>wrote:<br>>>>>> From: Melanie
<melanie@t-data.com><br>>>>>> Subject: Re: [Opensim-dev] Comms Manager<br>>>>>> To: opensim-dev@lists.berlios.de<br>>>>>> Date: Thursday, 26 February, 2009, 12:36 PM<br>>>>>> <br>>>>>> I don't think Grid and Asset modules need to load into<br>> region servers, and vice versa. At least not by the same interface. That<br>> interchangeability makes other things that are useful almost impossibly<br>complex.<br>>>>>> <br>>>>>> Melanie<br>>>>>> <br>>>>>> Stefan Andersson wrote:<br>>>>>>> No, didn't notice that, but I question why<br>>> Grid or Asset<br>>>> server<br>>>>>> modules should even be aware of that, regardless of how<br>the<br>> IScene<br>>>>> interface<br>>>>>> looks or what types that, in turn, pulls
in.<br>>>>>>> <br>>>>>>> Best regards,<br>>>>>>> Stefan Andersson<br>>>>>>> Tribal Media AB<br>>>>>>> <br>>>>>>> <br>>>>>>>> Date: Thu, 26 Feb 2009 12:29:19 +0000<br>>>>>>>> From: melanie@t-data.com<br>>>>>>>> To: opensim-dev@lists.berlios.de<br>>>>>>>> Subject: Re: [Opensim-dev] Comms Manager<br>>>>>>>> <br>>>>>>>> Hi,<br>>>>>>>> <br>>>>>>>> note that I used IScene sxclusively?<br>>>>>>>> <br>>>>>>>> Melanie<br>>>>>>>> <br>>>>>>>> Stefan Andersson wrote:<br>>>>>>>> > Um, yeah, having 'Scene' as a type in<br>>> anyhting<br>>>>> outside<br>>>
of<br>>>>>> the Region will lead to grief.<br>>>>>>>> > > > Suggestion:<br>>>>>>>> > > > > --- OpenSim.Framework: ---<br>>>>>>>> > > > > IGenericModule<br>>>>>>>> > > {<br>>>>>>>> > > Initialise();<br>>>>>>>> > > PostInitialise();<br>>>>>>>> > > }<br>>>>>>>> > > > > --- OpenSim.Region.Framework:<br>---<br>>>>>>>> > > ><br>>> <br>>>>>>>> > IRegionModule : IGenericModule<br>>>>>>>> > > {<br>>>>>>>> > > OnNewScene();<br>>>>>>>> > > OnSceneRemoved();<br>>>>>>>> > > }<br>>>>>>>> > > > > Best
regards,<br>>>>>>>> > Stefan Andersson<br>>>>>>>> > Tribal Media AB<br>>>>>>> <br>>>>>>> <br>>>>>>> <br>>>>>>> <br>>>>>>> <br>>>>> <br>>><br>------------------------------------------------------------------------<br>>>>>>> <br>>>>>>> _______________________________________________<br>>>>>>> Opensim-dev mailing list<br>>>>>>> Opensim-dev@lists.berlios.de<br>>>>>>> <br>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>>>> _______________________________________________<br>>>>>> Opensim-dev mailing list<br>>>>>> Opensim-dev@lists.berlios.de<br>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>>>>
<br>>>>>> <br>>>>>> <br>>>>>> <br>>>>>> <br>>>> <br>> ------------------------------------------------------------------------<br>>>>>> <br>>>>>> _______________________________________________<br>>>>>> Opensim-dev mailing list<br>>>>>> Opensim-dev@lists.berlios.de<br>>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>>> _______________________________________________<br>>>>> Opensim-dev mailing list<br>>>>> Opensim-dev@lists.berlios.de<br>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>>> <br>>>>> <br>>>>> <br>>> <br>>>>> <br>>>>> <br>>><br>------------------------------------------------------------------------<br>>>>>
<br>>>>> _______________________________________________<br>>>>> Opensim-dev mailing list<br>>>>> Opensim-dev@lists.berlios.de<br>>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>> _______________________________________________<br>>>> Opensim-dev mailing list<br>>>> Opensim-dev@lists.berlios.de<br>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>> <br>>>> <br>>>> <br>>>> <br>>>> <br>> ------------------------------------------------------------------------<br>>>> <br>>>> _______________________________________________<br>>>> Opensim-dev mailing list<br>>>> Opensim-dev@lists.berlios.de<br>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>> _______________________________________________<br>>> Opensim-dev
mailing<br>>> list<br>>> Opensim-dev@lists.berlios.de<br>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>> <br>>> <br>>> <br>>> <br>>> <br>>> <br>>> _______________________________________________<br>>> Opensim-dev mailing list<br>>> Opensim-dev@lists.berlios.de<br>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>> <br>>> <br>>> <br>>> <br>>><br>------------------------------------------------------------------------<br>>> <br>>> _______________________________________________<br>>> Opensim-dev mailing list<br>>> Opensim-dev@lists.berlios.de<br>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> <br>> <br>> <br>> ------------------------------------------------------------------------<br>> <br>>
_______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br></pre></blockquote></td></tr></table><br>