Why is it that you want to have some fixed, hardcoded behavior instead of leaving it to the module?
I thought what we ended up with was fine and agreeable to all, and now here you come again with region modules/regions accessing the core directly. I think that is a BadIdea(tm) to allow calls from regions into base directly. Melanie MW wrote: > Or a slightly different approach would be to add a security level as a a > param of the RegisterInterface method. > > So that a module could register multiple interface with different security > levels. Its then up to the application/loader which componets get access to > which interfaces (or in our implementation which registries those interfaces > would be added to) > > Anyway these are just ideas at the moment. The base system we have agreed to > (unless anyone else objects) is the IApplicationPlugin being able to register > to the ApplicationRegistry and to Scenes as it choices. Then having a > ApplicationPlugin that is a loader of IService modules. So these ideas are > just about how that loader handles things. > > --- On Thu, 26/2/09, MW <[email protected]> wrote: > From: MW <[email protected]> > Subject: Re: [Opensim-dev] Comms Manager > To: [email protected] > Date: Thursday, 26 February, 2009, 11:17 PM > > On that subject I keep coming back to the idea that there should be two > register Interface methods. > > > > And my lastest idea is about having the concept of Primary Registry and > Secondary Registry as a concept in the IServiceCore interface. > > > > The primary registry will be the protected Application registry, that > only privileged components should have access to. And the secondary > Registry is lower security. > > > > Then a IServiceModule can decide if it wants to register with the > secondary Registry at all. A module could also register different > interfaces to each Registry. So say a cut down interface to the > Secondary Registry. > > > > In the context of a ServiceModule being loaded into a Grid server, it > won't make any difference as (currently) they won't have any secondary > Registries, so those methods will just be stubbs. > > > > But in the context of it being loaded into the region server. The > loader will handle the automagic of adding all modules, that have > registered with the secondary Registry, to the Scenes. > > > > So we would have two register methods like: > > > > void RegisterPrimaryInterface<T>(T iface); > > void RegisterSecondaryInterface<T>(T iface); > > --- On Thu, 26/2/09, Melanie <[email protected]> wrote: > From: Melanie <[email protected]> > Subject: Re: [Opensim-dev] Comms Manager > To: [email protected], [email protected] > Date: Thursday, 26 February, 2009, 8:50 PM > > 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 > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
