[Opensim-dev] Comms Manager

[MW]

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 <melanie at t-data.com> wrote:
From: Melanie <melanie at t-data.com>
Subject: Re: [Opensim-dev] Comms Manager
To: michaelwri22 at yahoo.co.uk, opensim-dev at lists.berlios.de
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
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090226/700be4cd/attachment-0001.html>