[Opensim-dev] Scope and Purpose of IApplicationPlugins and IRegionModules

Melanie melanie at t-data.com
Thu Jul 3 10:37:26 UTC 2008


Hi,

region modules come in two flavors: private and shared. A private 
region module is instantiated once per region. A shared one is 
instatiated once and then it's init function is called again for 
each region loaded.

The difference then is that the shared modules tracks the regions 
itself, while the private module implicitly acts on one region only.

Some modules can't reasonably be done as a shared module, some could 
be either, and some must be shared to do the job, as they 
allocate/manage finite resources that are taken from an 
instance-wide pool.

So, there is a good case to be made for both types of region modules.

Yes, a means to exclude modules from certain regions might be useful 
to some. Currently, if a module wants to provide it's functionality 
to only a subset of the available regions, the module itself must 
make that choice. The loader doesn't have the option.

Because of the RegisterModuleInterface<IFace>(instance) and 
RequestModuleInterface<Iface>() methods in Scene, inter-module 
communications are possible, provided each module uses the interface 
and they know about each other at compile time.

This, and the Scene event manager hooks, and the client hooks, give 
modules themselves very fine grained control of the events they are 
interested in.

Script engines are special region modules, which are loaded in a 
separate pass. There can only be one. It must not be a shared 
module. And they're loaded last.

Outside of that, they are normal region modules.

Region modules are loaded/reinitialized at startup, and on dynamic 
region load. Many shared region modules, even the stock ones, are 
not prepared for a region going away, and to my knowledge there is 
no method/event to effect a "Region down" action, e.g. release 
memory allocated on the region's behalf. Of course this applies to 
shared modules only, since private ones will be unref'd and poof.

That pretty much summarizes what I know about region modules

Melanie

Justin Clark-Casey wrote:
> Ryan McDougall wrote:
>> In my poking about the loading code to get an idea of the scale of the
>> problem. I asked before about I*Plugin v. I(Region)Module, but I don't
>> think there was much of a clear answer...
>> 
>> The reason I am asking again is that I noticed:
>> 
>> 1. That a Scene takes a (Region)ModuleLoader as an argument to its
>> constructor. It doesn't appear to use this reference at all. 
>> 
>> Is there a Scene that needs to load its own RegionModules? Or is this an
>> example of bit-rotted code or inappropriate abstraction/coupling?
>> 
>> 2. That LoadRegionsPlugin (an IApplicationPlugin) uses its reference to
>> (Region)ModuleLoader (through OpenSimBase) to load RegionModules. 
>> 
>> Without knowing the semantic difference between a Plugin and Module, the
>> LoadRegionsPlugin looks a bit awkward. It appears as if its only purpose
>> is to choose between RegionLoaderFileSystem and RegionLoaderWebServer,
>> then load them within a plugin...
> 
> I wrote an overview post at 
> http://justincc.wordpress.com/2008/05/08/opensim-tech-basics-my-god-its-full-of-modules/
> about the different modular systems we have/had, though this does 
> contain information which is a little 'reverse engineered' too.  My 
> assumption was the plugins denoted application wide code that spans 
> regions (region information loading, load balancing, etc) , whilst 
> modules contained code specific to a region (chat, terrain, trees, etc.).
> 
> It feels intuitively a good idea to have application plugins and region 
> modules (the terminology *is* a little confusing) separate all the way 
> up to the user level.  For instance, one could conceivably run different 
> region modules on different regions, while an application plugin will 
> always apply to the whole server.  One could dynamically load and unload 
> some region modules, but with whole application plugins this could be 
> inappropriate (though maybe that it possible there as well...).
> 
> However, this could be a mistaken intuition, on really digging into the 
> code another conclusion may well be viable.
> 
>> 
>> Perhaps it might be more appropriate to make that selection in
>> OpenSimBase in order to keep all loading in one place? 
>> 
>> There are many ways I could do that, but it would take understanding the
>> purpose of the current and future design in order to make my plugin
>> loader a true solution that accommodates all use-cases.
>> 
>> Can we replace IRegionModules with IRegionPlugins and have PluginLoader
>> load them all?
>> 
>> Cheers,
>> 
>> _______________________________________________
>> 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