Again your looking for one solution where I don't think one fits or if it does we haven't found it. I don't see RegionLoaders or anything like that using the generic interface that I'm talking about. They should be separate and as you said the scene shouldn't have access to them.
But that doesn't mean we shouldn't provide the means for some modules to register with all scenes and the application without having to know about Scenes. Even with your system, the region loader could register itself with scenes if someone changed it to do so. So the same if we have some sort of RegisterWithAll method. It can be miss used but we can't stop that anyway. So I'm still for a system that allows modules that don't need to know about Scenes. Again some modules will be like you said and want to have complete control of what scenes they register with, but some won't. --- 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, 6:00 PM Well, here goes 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. That can be done with what you suggested > 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. And that is where we diverge. I believe top allow unchecked access to modules never writte to be used bby scenes, from scenes, would expose functionality to scenes that they should not have access to. It would be an internal privilege escalation, if a scene could, for instance, call a method in the region loader directly and find out about other scenes. Or unload another scene, etc. That is why I object to having those modules callable from anywhere. Some simple boilerplate code that, in the context of a grid server, would simply do nothing, but in the context of a region server would attach to scenes and expose a narrowly tailored interface there seems to be much more secure. We could even provide an abstract base class that a module may inherit from to get that functionality provided for it. But directly calling into that level of the app from scene? There be dragons! > 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. Please see above. It can easily be done to expose an interface to Scene that is meant to be used in a Scene context and exposes only things Scene should be able to do. > 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. No. Explicit implementation in the module, or inheriting an abstract base that provides it, to reduce code duplication. > 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. No. The modules would do that. In my example, the Region Loader is JustAnotherModule(tm). The IServiceCore (which you came up with) has no knowledge of it. The key here is that "loader", the result of RequestModuleInterface<IRegionLoader>(), would be null in a grid server and not null in a region server. The remaining stuff (Region hooking) can depend on that, making the module work in a grid server context as well as a region server context, having an interface that can safely be accessed from a scene and is explicit, and avoiding access to modules that don't want to talk to scenes at all. > This it does get complex, where the simply solution and the one I favour is > to just have a sharedRegistry that scenes can access. That is what I wouldn't like to have. Too dangerous! > 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. I think my idea can serve your purpose without forcing everyone to compromise internal application security and encapsulation. Melanie _______________________________________________ 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
