<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Did you actually read what I said? I said the base idea of
ApplicationPlugins being able to register with the ApplicationRegistry
and with scenes as they wish is what we were going with. But we would
then have a Plugin that was a loader of IServiceModules. <br>
<br>
The ideas I was throwing out there were how that plugin handles things.
As was actually in answer to your comment about do we want all
ServiceModules registered with the regions. So I was thinking of a
method that allows ServiceModules to decide which they actually
register to.<br>
<br>
Again I never mentioned the Regions/Region modules accessing the core
at all. I said the Service modules would be able to use diferent
Registry methods to say if they should be added to the Scene Registries
or not. I'd say thats a step away from a hardcode behavior of having
all Service Mdoules registered with the Scenes. Which we agreed earlier.<br><br>No matter what you think, I think there should be a ServiceModule system that doesn't need to know about Scenes. Now we have agreed that this will be bult on top of the IApplicationPlugin system. So now I'm just talking about how the automagic will work. <br><br>--- On <b>Thu, 26/2/09, Melanie <i><melanie@t-data.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">From: Melanie <melanie@t-data.com><br>Subject: Re: [Opensim-dev] Comms Manager<br>To: michaelwri22@yahoo.co.uk, opensim-dev@lists.berlios.de<br>Date: Thursday, 26 February, 2009, 11:51 PM<br><br><pre>Why is it that you want to have some fixed, hardcoded behavior instead of<br>leaving it to the module?<br><br>I thought what we ended up with was fine and agreeable to all, and now here you<br>come again with region modules/regions accessing
the core directly. I think that<br>is a BadIdea(tm) to allow calls from regions into base directly.<br><br>Melanie<br><br>MW wrote:<br>> Or a slightly different approach would be to add a security level as a a<br>param of the RegisterInterface method. <br>> So that a module could register multiple interface with different security<br>levels. Its then up to the application/loader which componets get access to<br>which interfaces (or in our implementation which registries those interfaces<br>would be added to)<br>> <br>> Anyway these are just ideas at the moment. The base system we have agreed<br>to (unless anyone else objects) is the IApplicationPlugin being able to register<br>to the ApplicationRegistry and to Scenes as it choices. Then having a<br>ApplicationPlugin that is a loader of IService modules. So these ideas are just<br>about how that loader handles things. <br>> --- On Thu, 26/2/09, MW <michaelwri22@yahoo.co.uk>
wrote:<br>> From: MW <michaelwri22@yahoo.co.uk><br>> Subject: Re: [Opensim-dev] Comms Manager<br>> To: opensim-dev@lists.berlios.de<br>> Date: Thursday, 26 February, 2009, 11:17 PM<br>> <br>> On that subject I keep coming back to the idea that there should be two<br>register Interface methods.<br>> <br>> <br>> <br>> And my lastest idea is about having the concept of Primary Registry and<br>> Secondary Registry as a concept in the IServiceCore interface.<br>> <br>> <br>> <br>> The primary registry will be the protected Application registry, that<br>> only privileged components should have access to. And the secondary<br>> Registry is lower security.<br>> <br>> <br>> <br>> Then a IServiceModule can decide if it wants to register with the<br>> secondary Registry at all. A module could also register different<br>> interfaces to each Registry. So say a cut down interface to
the<br>> Secondary Registry.<br>> <br>> <br>> <br>> In the context of a ServiceModule being loaded into a Grid server, it<br>> won't make any difference as (currently) they won't have any<br>secondary<br>> Registries, so those methods will just be stubbs.<br>> <br>> <br>> <br>> But in the context of it being loaded into the region server. The<br>> loader will handle the automagic of adding all modules, that have<br>> registered with the secondary Registry, to the Scenes.<br>> <br>> <br>> <br>> So we would have two register methods like:<br>> <br>> <br>> <br>> void RegisterPrimaryInterface<T>(T iface);<br>> <br>> void RegisterSecondaryInterface<T>(T iface);<br>> <br>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com> wrote:<br>> From: Melanie <melanie@t-data.com><br>> Subject: Re: [Opensim-dev] Comms Manager<br>> To: michaelwri22@yahoo.co.uk,
opensim-dev@lists.berlios.de<br>> Date: Thursday, 26 February, 2009, 8:50 PM<br>> <br>> Yes, Sounds good. It will, of course, expose _all_ service modules to all<br>> Scenes. If that is wanted in the long run is another question.<br>> <br>> But, +1<br>> <br>> Melanie<br>> <br>> MW wrote:<br>>> Well I think the compromise we basically agreed on is that we go with<br>> IApplicationPlugins being able to register to the ApplicationRegistry and<br>also<br>> (via OnRegionCreated events) to the scenes. <br>>> And then for the service modules, we can have a loader that itself is<br>a<br>> IApplicationPlugin that loads the service<br>> modules (IServiceModule) and does the<br>> auto registering for them. This way at least this automagic is out of the<br>core<br>> opensimbase (etc). <br>>> --- On Thu, 26/2/09, Melanie <melanie@t-data.com> wrote:<br>>> From: Melanie
<melanie@t-data.com><br>>> Subject: Re: [Opensim-dev] Comms Manager<br>>> To: opensim-dev@lists.berlios.de<br>>> Date: Thursday, 26 February, 2009, 8:37 PM<br>>> <br>>> Well, if it gets that evil, then we might as well stick with plan A.<br>As<br>> long as this "All region" registration is in that specific<br>application<br>> module, and not global.<br>>> I believe modules written to load into region servers should also<br>handle<br>> this explicitly.<br>>> <br>>> Melanie<br>>> <br>>> Justin Clark-Casey wrote:<br>>>> MW wrote:<br>>>>> A couple of issues/questions are:<br>>>>> <br>>>>> How would a Region/ServiceModule say what interface it wanted<br>to<br>> register, it might implement a<br>> couple but only want to register one,<br>>> or <br>>>>> it might want to register its class type.<br>>>>
<br>>>> :( Yeah, you're right - for some reason I forgot that you<br>have to<br>>> explicitly name the interface when you make the <br>>>> RegisterModuleInterface() call. e.g.<br>>>> <br>>>> RegisterModuleInterface<IHappyModuleMethods>(this);<br>>>> <br>>>> I don't believe this can be achieved via reflection.<br>>>> <br>>>> However, I think you could still indicate which interfaces should<br>be<br>>> exposed to the region by adding attributes to them. <br>>>> For example, in Initialise() you could do something like<br>>>> <br>>>> <br>> RegistryManager.RegisterModuleInterface<IHappyModuleMethods>(this);<br>>>> <br>>>> And annotate the interfaces with something like<br>>>> <br>>>> [ServiceInterface]<br>>>> public interface IHappyModuleMethods { ...<br>> }<br>>>>
<br>>>> In a region server, the interface would be added to the region<br>> registry. <br>>> In a grid server, the interface would be added <br>>>> to the grid registry.<br>>>> <br>>>> If one wanted a non-region 'application only' interface in<br>the<br>>> region server, then one could perhaps also add<br>>>> <br>>>> [ApplicationInterface]<br>>>> public interface IEvilApplicationMethods { ... }<br>>>> <br>>>> with<br>>>> <br>>>> <br>>> <br>><br>RegistryManager.RegisterModuleInterface<IEvilApplicationMethods>(this);<br>>>> <br>>>> In a region service this could be added only to the application<br>> registry<br>>> and not the region registry. In a grid service <br>>>> it would still be added to the single grid registry.<br>>>> <br>>>> This is getting messy though and I'm not
sure how much it buys<br>you<br>>> over simply indicating the 'type' (service or<br>> <br>>>> application) when you initially register it. Mostly this all<br>becomes<br>> a<br>>> refinement of your earlier<br>>>> <br>>>> void RegisterInterfaceToAllRegistries<T>(T iface);<br>>>> <br>>>>> <br>>>>> And I'm taking it we would still have the<br>ApplicationPlugin<br>> that<br>>> could <br>>>>> register with what regions it wanted, so would still need the<br>> Scene.RegisterModule<>() interface for them.<br>>>>> <br>>>>> <br>>>>> --- On *Thu, 26/2/09, Justin Clark-Casey<br>>> /<jjustincc@googlemail.com>/* <br>>>>> wrote:<br>>>>> <br>>>>> 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>>>>> MW wrote:<br>>>>> <br>> > I'm not actually bothered about the interface per se.<br>>> What I require<br>>>>> is > to be able to dynamically load generic modules<br>> that no where<br>>> in that <br>>>>> > module does it know about IScene/Scene.<br>>>>> > > I actually see your approach as complex<br>because<br>> it demands<br>>> they need to <br>>>>> > know how to register to a scene themselves when these<br>> types<br>>> shouldn't <br>>>>> > need to know. The types of modules I mean are ones<br>where<br>> they<br>>> just want <br>>>>> > to register with the Core/Application and be
accessed<br>> from<br>>> anywhere in <br>>>>> ><br>>>>> the application.<br>>>>> > > Of course this module type doesn't fit<br>all<br>> needs, but<br>>> thats what<br>>>>> I'm > saying its not right to try to find a<br>single<br>> solution<br>> that<br>>> fits all <br>>>>> > needs and turns out to be more complex than some<br>modules<br>>> require. And we <br>>>>> > shouldn't rule out such generic modules.<br>>>>> > > Now we could still do meet the above<br>requirement<br>> with you<br>>> system, but it <br>>>>> > would mean doing some automagic in a<br>ApplicationPlugin<br>> (or<br>>> whatever <br>>>>> > interface they used) loader.<br>>>>> > > As the loader would have to provide its
own<br>> IServiceCore<br>>> implementation, <br>>>>> > that it passed to the IServiceModules that it loaded,<br>> then it<br>>> would need <br>>>>> > to as your examples show handle scene creation and<br>> register<br>>> the all the <br>>>>> > IServiceModules with those.<br>>>>> > > This it does get complex, where the simply<br>> solution and<br>> the<br>>> one I favour <br>>>>> > is to just have a sharedRegistry that scenes can<br>access.<br>>>>> The whole > automagic came from me trying to find<br>a<br>> compromise that met<br>>> your ideas. <br>>>>> > I really dislike it though, but we just need to find<br>a<br>>> compromise as we <br>>>>> > both have slighly different ideas and requirements.<br>>>>> > > Thats
why I would like to hear from other<br>> people.<br>>>>> <br>>>>> Okay, it seems to me that the chief problem now is that MW<br>> would<br>>> like to<br>>>>> exposed service module methods to regions without<br>having<br>> to put any IScene methods in the module code,<br>>> allowing it to be<br>>>>> used for both the region server and grid servers.<br>>>>> <br>>>>> This is possible if all the service methods are exposed to<br>the<br>>> <br>> region. <br>>>>> However, Melanie doesn't like this because it will<br>> expose some methods that regions should arguably not be able<br>>> to get at<br>>>>> (such as IInventoryService.CreateNewUserInventory()).<br>>>>> <br>>>>> I would tend to think that we shouldn't expose such<br>> service<br>>> methods
to<br>>>>> regions.<br>>>>> <br>>>>> Neither side likes automagic by the<br>>>>> core code, but I think a little bit of it<br>>>>> will help here. Instead of having methods such as<br>>>>> <br>>>>> void RegisterInterfaceToAllRegistries<T>(T iface);<br>>>>> <br>>>>> we instead annotate service modules with [RegionModule]<br>and<br>> region<br>>> interfaces<br>>>>> with [RegionInterface]. Grid modules which can also<br>> provide region services are annotated in this way. <br>>> When<br>> the<br>>>>> core code goes to load them, the [RegionInterface]<br>tagged<br>> interfaces are automatically registered<br>>> with the<br>>>>> region registry. This replaces <br>RegisterModuleInterface().<br>>>>>
<br>>>>> It also requires that IServiceModule and IRegionModule are<br>>> collapsed together,<br>>>>> by removing the IScene references in IRegionModule. <br>> Instead, these are passed in via the OnNewScene()<br>>> event talked<br>>>>> about earlier.<br>>>>> <br>>>>> In this way, service/application modules that aren't<br>>> interested in scenes<br>>>>> don't need to do any extra work apart from tagging<br>the<br>> module/interfaces appropriately, avoiding the<br>>>>> boilerplate of<br>>>>> separately registering the interface to each region. <br>The<br>> regions still don't have access to<br>>> <br>> inter-service/non-region<br>>>>> interfaces.<br>>>>> <br>>>>> This does require a separate service registry hidden from<br>the<br>>>
Region/Scene so<br>>>>> that services can communicate among themselves (e.g.<br>the<br>> user service needs to call the inventory<br>>> service to create<br>>>>> new user inventories). There would be 2 registries in<br>> total.<br>>>>> <br>>>>> Please excuse me if I haven't fully grokked all the<br>> previous<br>>> posts on this<br>>>>> thread.<br>>>>> <br>>>>> <br>>>>> <br>>>>> <br>>>>> <br>>><br>------------------------------------------------------------------------<br>>>>> <br>>>>> _______________________________________________<br>>>>> Opensim-dev mailing list<br>>>>> Opensim-dev@lists.berlios.de<br>>>>> <br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>>> <br>>>> <br>>>
_______________________________________________<br>>> Opensim-dev mailing list<br>>> Opensim-dev@lists.berlios.de<br>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>>> <br>>> <br>>> <br>>> <br>>><br>------------------------------------------------------------------------<br>>> <br>>> _______________________________________________<br>>> Opensim-dev mailing list<br>>> Opensim-dev@lists.berlios.de<br>>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> <br>> <br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> <br>> <br>> <br>> ------------------------------------------------------------------------<br>> <br>>
_______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br></pre></blockquote></td></tr></table><br>