Justin Clark-Casey wrote: > 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.
It may add a bit of time, but I don't think it would be much. If going
after build times is a goal, I think that's probably a seperate topic.
Nant (like ant) does a lot of dumb things that waste time.
>>> 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 :-)
I'd be much more of a fan of having each module a seperate dll. Files
are cheap too. :) And that makes it very clear to people what they are
loading, and what they aren't loading.
> 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 :-)
I'd be a fan of that as well. More importantly, I think we need to get
down to 1 config system and 1 plugin system for the project. Right now
I think we're still at 2 or 3 per, which makes it painful all around.
-Sean
--
Sean Dague / Neas Bade
[email protected]
http://dague.net
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
