<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">A couple of issues/questions are:<br><br>How would a

Region/ServiceModule say what interface it wanted to register, it might

implement a couple but only want to register one, or it might want to

register its class type.<br><br>And I'm taking it we would still have

the ApplicationPlugin that could register with what regions it wanted,

so would still need the Scene.RegisterModule<>() interface for

them.<br><br><br>--- On <b>Thu, 26/2/09, Justin Clark-Casey <i><jjustincc@googlemail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">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><pre>MW wrote:<br>> I'm not actually bothered about the interface per se. What I require<br>is <br>> to be able to dynamically load generic modules that no where in that <br>> module does it know about IScene/Scene.<br>> <br>> I actually see your approach as complex because it demands they need to <br>> know how to register to a scene themselves when these types shouldn't <br>> need to know. The types of modules I mean are ones where they just want <br>> to register with the Core/Application and be accessed from anywhere in <br>>

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

 The whole <br>> automagic came from me trying to find a compromise that met your ideas. <br>> I really dislike it though, but we just need to find a 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 like to<br>exposed service module methods to regions <br>without having to put any IScene methods in the module code, 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. <br>However, Melanie doesn't like this because it <br>will expose some methods that regions should arguably not be able to get at<br>(such as <br>IInventoryService.CreateNewUserInventory()).<br><br>I would tend to think that we shouldn't expose such service methods to<br>regions.<br><br>Neither side likes automagic by the

 core code, but I think a little bit of it<br>will help here.  Instead of having methods <br>such as<br><br>void RegisterInterfaceToAllRegistries<T>(T iface);<br><br>we instead annotate service modules with [RegionModule] and region interfaces<br>with [RegionInterface].  Grid modules <br>which can also provide region services are annotated in this way.  When the<br>core code goes to load them, the <br>[RegionInterface] tagged interfaces are automatically registered with the<br>region registry.  This replaces <br>RegisterModuleInterface().<br><br>It also requires that IServiceModule and IRegionModule are collapsed together,<br>by removing the IScene references in <br>IRegionModule.  Instead, these are passed in via the OnNewScene() event talked<br>about earlier.<br><br>In this way, service/application modules that aren't interested in scenes<br>don't need to do any extra work apart from <br>tagging the module/interfaces appropriately, avoiding the

 boilerplate of<br>separately registering the interface to each <br>region.  The regions still don't have access to inter-service/non-region<br>interfaces.<br><br>This does require a separate service registry hidden from the Region/Scene so<br>that services can communicate among <br>themselves (e.g. the user service needs to call the inventory 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 posts on this<br>thread.<br><br><br></pre></blockquote></td></tr></table><br>