[Opensim-dev] proposal: cleanup and break up region modules

Justin Clark-Casey jjustincc at googlemail.com
Wed Jan 28 20:11:28 UTC 2009


Dr Scofield wrote:
> Justin Clark-Casey wrote:
>> Dr Scofield wrote:
>>> i've been looking at where region modules live in our source tree --- 
>>> OpenSim/Region/Modules and OpenSim/Region/Environment/Modules --- and 
>>> how they get bundled:
>>>
>>>     * modules in OpenSim/Region/Modules get their own private DLL
>>>     * OpenSim/Region/Environment/Modules get lumped into ONE gigantic DLL
>>>
>>> off the 3 modules living in OpenSim/Region/Modules 2 might be good 
>>> candidate for forge project: python and SvnSerializer. the third really 
>>> belongs to the Terrain region module and seems to contain the default 
>>> terrain effects.
>>>
>>> i think it would make sense to
>>>
>>>     * have all region modules living in the same neighborhood (i'd
>>>       prefer OpenSim/Region/Modules), the current layout is a bit confusing
>> Don't we need to make a distinction between 'service' modules (such as the REST module) and scene/environment modules 
>> though?  The former are not attached to a scene (and may well never be concerned with scene code) while the latter are 
>> very much scene related.
> 
> that would be another step. first i'd like to get the modules settled in the
> same neighborhood.
> 
>>>     * break up the region module super-DLL so that each region module
>>>       gets a DLL of its own
>> At least on mono, I'm guessing that this would vastly expand build times.  Certainly at the moment, each invocation of 
>> mono to build a new assembly appears to take far longer than building many files in a single dll.
> 
> vastly?

Maybe this is a slight exaggeration but I'm anticipating that the build time would be much longer.  I'm happy to be 
proved wrong on this point.  Maybe this seems a minor thing but long build times are such a pain in the ass.

> 
> 
>> I also tend to think of the current modules in OpenSim/Region/Environment/Modules as fairly core modules that one would 
>> expect to be packaged together, and which it would be inconvenient to split up.
> 
> hmm...that kind of goes against the idea of them being modules, i'd think :-)
> 
> 

Does it?  Isn't this just a convenient way of packaging the core modules that almost everybody is going to need to run 
their OpenSim (though I would admit that some of the modules in there arguably aren't core...)

I feel that what would be really useful is a core mechanism for enabling/disabling modules which doesn't rely on the 
module itself having that option.  This would be simpler and might make the question of whether there are lots of 
modules bundled in a single dll moot (since you can just enable/disable them with separate config entries - and storage 
space for dlls is cheap :-)

Which in itself leads me on to the question of splitting up the massive monolithic config file.  I don't know about 
other people, but I find it a pain to deal with.  I feel that these kinds of changes would be really valuable whilst 
rearranging the module spaces is kind of nice to have but doesn't seem the most pressing issue right now.  But that's 
just my opinion :-)

-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com



More information about the Opensim-dev mailing list