[Opensim-dev] Module/Plugin Loading

[Dr Scofield]

Sean Dague wrote:
> On Thu, Jun 26, 2008 at 09:49:11AM +0200, Stefan Andersson wrote:
>   
>>> Those attributes are just syntactic sugar. Once you start really using> the features of Mono.Addins you're best of configuring your addins> with the XML file.
>>>       
>> That's probably the way to go, yeah.
>>  > Its also worth nothing that there is nothing in Mono.Addin's XML> config file that replaces anything in OpenSim.ini, nor vice versa.> They are completely orthogonal configuration files which are> unrelated. There is no OpenSim v. Mono.Addins dilemma.
>> I think that what some of us are worried about is the configuration creep; there's slowly getting more and more ways of configuring various aspects of OpenSim, and each configuration is something more to grok in order to use.
>>  
>> afaik, we have Prebuild, log4net, NHibernate, Nini, the database
>> configuration files, the opensim.ini, various grid inis, some settings
>> are stored in a yap database, the region configs - and now Mono
>> Addins. Each following different syntax and structure.
>>     
>
> Fortunately this list actually has been pruned down (at least I've been
> trying :))
>  * .yap have been pulled (db4o is no longer in the tree)
>  * database configs are now deprecated, you can fully specify them all
>    as connection strings in either opensim.ini or grid configs (there
>    are even user messages telling people that if they are using the old
>    model).
>  * NHibernate doesn't need any of it's own user changable config outside
>    of opensim.ini.  The nhibernate config is just annotations to make
>    some log messages go away.
>
> So that does get us down to:
>  * estate settings
>  * grid configs
>  * Nini based stuff (opensim.ini, stock content libraries)
>  * .configs on .exe files for log4net
>  * region configs
>
> But that's still *a lot*, especially as each of those are different.
> One of the reasons no one has touched estate settings is that it's the
> deepest darkest part of config.  Our first config mechanism.  There be
> dragons there, and not the anthropomorphic friendly type. :)
>
>   
>> So, we're starting to get something like what we're trying to solve
>> with unifying the plugin architecture.
>>     
>
> +1.  100% agreed.
>
>   
>> At some point, we need to look at unifying our configs. Introducing
>> Nini was a stab at that, but seems to have lost momentum. Personally,
>> I have somewhat lost faith in Nini, as it doesn't really seem to
>> handle hierarchical data on several instances too well.
>>     
>
> Is there a good example on that?  The Nini XML used for assets doesn't
> seem too bad.  I do agree that on the ini side we've got some work
> there.
>
> Having looked, and thrown up my hands on modding estate settings, I'd
> suggest Nini replacements for the rest of the non nini, custom loaders,
> would help *a lot* in cleaning up the source base, and making it make
> more sense.
>
> We may also want to switch OpenSim.ini to an xml file if we want more
> nesting.  Big OpenSim.ini files definitely seem overwhelming at this
> point, though not too unweildly.
>
>   
hmm...personally, i hate XML config files. the OpenSim.ini style is much 
easier to use and less cluttered.

    dirk

-- 
dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab
SL: dr scofield ---- drscofield at xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/
RL: hud at zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/