[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