Yes, Sounds good. It will, of course, expose _all_ service modules to all Scenes. If that is wanted in the long run is another question.
But, +1 Melanie MW wrote: > 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. > > 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). > > --- On Thu, 26/2/09, Melanie <[email protected]> wrote: > From: Melanie <[email protected]> > Subject: Re: [Opensim-dev] Comms Manager > To: [email protected] > Date: Thursday, 26 February, 2009, 8:37 PM > > Well, if it gets that evil, then we might as well stick with plan A. > As long as this "All region" registration is in that specific > application module, and not global. > I believe modules written to load into region servers should also > handle this explicitly. > > Melanie > > Justin Clark-Casey wrote: >> MW wrote: >>> A couple of issues/questions are: >>> >>> 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. >> >> :( Yeah, you're right - for some reason I forgot that you have to > explicitly name the interface when you make the >> RegisterModuleInterface() call. e.g. >> >> RegisterModuleInterface<IHappyModuleMethods>(this); >> >> I don't believe this can be achieved via reflection. >> >> However, I think you could still indicate which interfaces should be > exposed to the region by adding attributes to them. >> For example, in Initialise() you could do something like >> >> RegistryManager.RegisterModuleInterface<IHappyModuleMethods>(this); >> >> And annotate the interfaces with something like >> >> [ServiceInterface] >> public interface IHappyModuleMethods { ... } >> >> In a region server, the interface would be added to the region registry. > In a grid server, the interface would be added >> to the grid registry. >> >> If one wanted a non-region 'application only' interface in the > region server, then one could perhaps also add >> >> [ApplicationInterface] >> public interface IEvilApplicationMethods { ... } >> >> with >> >> > RegistryManager.RegisterModuleInterface<IEvilApplicationMethods>(this); >> >> In a region service this could be added only to the application registry > and not the region registry. In a grid service >> it would still be added to the single grid registry. >> >> This is getting messy though and I'm not sure how much it buys you > over simply indicating the 'type' (service or >> application) when you initially register it. Mostly this all becomes a > refinement of your earlier >> >> void RegisterInterfaceToAllRegistries<T>(T iface); >> >>> >>> 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. >>> >>> >>> --- On *Thu, 26/2/09, Justin Clark-Casey > /<[email protected]>/* >>> wrote: >>> >>> From: Justin Clark-Casey <[email protected]> >>> Subject: Re: [Opensim-dev] Comms Manager >>> To: [email protected] >>> Date: Thursday, 26 February, 2009, 7:07 PM >>> >>> MW wrote: >>> > I'm not actually bothered about the interface per se. > What I require >>> is >>> > to be able to dynamically load generic modules that no where > in that >>> > module does it know about IScene/Scene. >>> > >>> > I actually see your approach as complex because it demands > they need to >>> > know how to register to a scene themselves when these types > shouldn't >>> > need to know. The types of modules I mean are ones where they > just want >>> > to register with the Core/Application and be accessed from > anywhere in >>> > >>> 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 >>> > automagic came from me trying to find a compromise that met > your ideas. >>> > I really dislike it though, but we just need to find a > compromise as we >>> > both have slighly different ideas and requirements. >>> > >>> > Thats why I would like to hear from other people. >>> >>> Okay, it seems to me that the chief problem now is that MW would > like to >>> exposed service module methods to regions >>> without having to put any IScene methods in the module code, > allowing it to be >>> used for both the region server and grid >>> servers. >>> >>> 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. > When the >>> core code goes to load them, the >>> [RegionInterface] tagged interfaces are automatically registered > with the >>> region registry. This replaces >>> RegisterModuleInterface(). >>> >>> It also requires that IServiceModule and IRegionModule are > collapsed together, >>> by removing the IScene references in >>> IRegionModule. Instead, these are passed in via the OnNewScene() > event talked >>> about earlier. >>> >>> In this way, service/application modules that aren't > interested in scenes >>> don't need to do any extra work apart from >>> tagging the module/interfaces appropriately, avoiding the >>> boilerplate of >>> separately registering the interface to each >>> region. The regions still don't have access to > inter-service/non-region >>> interfaces. >>> >>> This does require a separate service registry hidden from the > Region/Scene so >>> that services can communicate among >>> themselves (e.g. the user service needs to call the inventory > service to create >>> new user inventories). There would be 2 >>> registries in total. >>> >>> Please excuse me if I haven't fully grokked all the previous > posts on this >>> thread. >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> [email protected] >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
