<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Well I think the compromise we basically agreed on is that we go with IApplicationPlugins being able to register to the ApplicationRegistry and also (via OnRegionCreated events) to the scenes. <br><br>And then for the service modules, we can have a loader that itself is a IApplicationPlugin that loads the service modules (IServiceModule) and does the auto registering for them. This way at least this automagic is out of the core opensimbase (etc). <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: opensim-dev@lists.berlios.de<br>Date: Thursday, 26 February, 2009, 8:37 PM<br><br><pre>Well, if it gets that evil, then we might as well stick

 with plan A. <br>As long as this "All region" registration is in that specific <br>application module, and not global.<br>I believe modules written to load into region servers should also <br>handle this explicitly.<br><br>Melanie<br><br>Justin Clark-Casey wrote:<br>> MW wrote:<br>>> A couple of issues/questions are:<br>>> <br>>> How would a Region/ServiceModule say what interface it wanted to <br>>> register, it might implement a couple but only want to register one,<br>or <br>>> it might want to register its class type.<br>> <br>> :(  Yeah, you're right - for some reason I forgot that you have to<br>explicitly name the interface when you make the <br>> RegisterModuleInterface() call.  e.g.<br>> <br>> RegisterModuleInterface<IHappyModuleMethods>(this);<br>> <br>> I don't believe this can be achieved via reflection.<br>> <br>> However, I think you could still indicate which interfaces

 should be<br>exposed to the region by adding attributes to them. <br>>   For example, in Initialise() you could do something like<br>> <br>> RegistryManager.RegisterModuleInterface<IHappyModuleMethods>(this);<br>> <br>> And annotate the interfaces with something like<br>> <br>> [ServiceInterface]<br>> public interface IHappyModuleMethods { ... }<br>> <br>> In a region server, the interface would be added to the region registry. <br>In a grid server, the interface would be added <br>> to the grid registry.<br>> <br>> If one wanted a non-region 'application only' interface in the<br>region server, then one could perhaps also add<br>> <br>> [ApplicationInterface]<br>> public interface IEvilApplicationMethods { ... }<br>> <br>> with<br>> <br>><br>RegistryManager.RegisterModuleInterface<IEvilApplicationMethods>(this);<br>> <br>> In a region service this could be added only to the

 application registry<br>and not the region registry.  In a grid service <br>> it would still be added to the single grid registry.<br>> <br>> This is getting messy though and I'm not sure how much it buys you<br>over simply indicating the 'type' (service or <br>> application) when you initially register it.  Mostly this all becomes a<br>refinement of your earlier<br>> <br>> void RegisterInterfaceToAllRegistries<T>(T iface);<br>> <br>>> <br>>> And I'm taking it we would still have the ApplicationPlugin that<br>could <br>>> register with what regions it wanted, so would still need the <br>>> Scene.RegisterModule<>() interface for them.<br>>> <br>>> <br>>> --- On *Thu, 26/2/09, Justin Clark-Casey<br>/<jjustincc@googlemail.com>/* <br>>> wrote:<br>>> <br>>>     From: Justin Clark-Casey <jjustincc@googlemail.com><br>>>     Subject: Re: [Opensim-dev]

 Comms Manager<br>>>     To: opensim-dev@lists.berlios.de<br>>>     Date: Thursday, 26 February, 2009, 7:07 PM<br>>> <br>>>     MW wrote:<br>>>     > I'm not actually bothered about the interface per se.<br>What I require<br>>>     is <br>>>     > to be able to dynamically load generic modules that no where<br>in that <br>>>     > module does it know about IScene/Scene.<br>>>     > <br>>>     > I actually see your approach as complex because it demands<br>they need to <br>>>     > know how to register to a scene themselves when these types<br>shouldn't <br>>>     > need to know. The types of modules I mean are ones where they<br>just want <br>>>     > to register with the Core/Application and be accessed from<br>anywhere in <br>>>     ><br>>>      the application.<br>>>     > <br>>>     > Of course this module type

 doesn't fit all needs, but<br>thats what<br>>>     I'm <br>>>     > saying its not right to try to find a single solution that<br>fits all <br>>>     > needs and turns out to be more complex than some modules<br>require. And we <br>>>     > shouldn't rule out such generic modules.<br>>>     > <br>>>     > Now we could still do meet the above requirement with you<br>system, but it <br>>>     > would mean doing some automagic in a ApplicationPlugin (or<br>whatever <br>>>     > interface they used) loader.<br>>>     > <br>>>     > As the loader would have to provide its own IServiceCore<br>implementation, <br>>>     > that it passed to the IServiceModules that it loaded, then it<br>would need <br>>>     > to as your examples show handle scene creation and register<br>the all the <br>>>     > IServiceModules with those.<br>>>     >

 <br>>>     > This it does get complex, where the simply solution and the<br>one I favour <br>>>     > is to just have a sharedRegistry that scenes can access.<br>>>      The whole <br>>>     > automagic came from me trying to find a compromise that met<br>your ideas. <br>>>     > I really dislike it though, but we just need to find a<br>compromise as we <br>>>     > both have slighly different ideas and requirements.<br>>>     > <br>>>     > Thats why I would like to hear from other people.<br>>> <br>>>     Okay, it seems to me that the chief problem now is that MW would<br>like to<br>>>     exposed service module methods to regions <br>>>     without having to put any IScene methods in the module code,<br>allowing it to be<br>>>     used for both the region server and grid <br>>>     servers.<br>>> <br>>>     This is possible if all the

service methods are exposed to the region.  >>     However, Melanie doesn't like this because it  >>     will expose some methods that regions should arguably not be able to get at >>     (such as  >>     IInventoryService.CreateNewUserInventory()). >>  >>     I would tend to think that we shouldn't expose such service methods to >>     regions. >>  >>     Neither side likes automagic by the >>      core code, but I think a little bit of it >>     will help here.  Instead of having methods  >>     such as >>  >>     void RegisterInterfaceToAllRegistries<T>(T iface); >>  >>     we instead annotate service modules with [RegionModule] and region interfaces >>     with [RegionInterface].  Grid modules  >>     which can also provide region services are annotated in this way.

 <br>When the<br>>>     core code goes to load them, the <br>>>     [RegionInterface] tagged interfaces are automatically registered<br>with the<br>>>     region registry.  This replaces <br>>>     RegisterModuleInterface().<br>>> <br>>>     It also requires that IServiceModule and IRegionModule are<br>collapsed together,<br>>>     by removing the IScene references in <br>>>     IRegionModule.  Instead, these are passed in via the OnNewScene()<br>event talked<br>>>     about earlier.<br>>> <br>>>     In this way, service/application modules that aren't<br>interested in scenes<br>>>     don't need to do any extra work apart from <br>>>     tagging the module/interfaces appropriately, avoiding the<br>>>      boilerplate of<br>>>     separately registering the interface to each <br>>>     region.  The regions still don't have access

 to<br>inter-service/non-region<br>>>     interfaces.<br>>> <br>>>     This does require a separate service registry hidden from the<br>Region/Scene so<br>>>     that services can communicate among <br>>>     themselves (e.g. the user service needs to call the inventory<br>service to create<br>>>     new user inventories).  There would be 2 <br>>>     registries in total.<br>>> <br>>>     Please excuse me if I haven't fully grokked all the previous<br>posts on this<br>>>     thread.<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>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>