[Opensim-dev] Module/Plugin Loading

[Sean Dague]

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.

    -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080626/391166ef/attachment-0001.pgp>