[Opensim-dev] Comms Manager

[Melanie]

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