[Opensim-dev] Comms Manager
Melanie
melanie at t-data.com
Thu Feb 26 20:50:14 UTC 2009
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 <melanie at t-data.com> wrote:
> From: Melanie <melanie at t-data.com>
> Subject: Re: [Opensim-dev] Comms Manager
> To: opensim-dev at lists.berlios.de
> 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
> /<jjustincc at googlemail.com>/*
>>> wrote:
>>>
>>> From: Justin Clark-Casey <jjustincc at googlemail.com>
>>> Subject: Re: [Opensim-dev] Comms Manager
>>> To: opensim-dev at lists.berlios.de
>>> 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
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
More information about the Opensim-dev
mailing list