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
