[Opensim-dev] Module/Plugin Loading

[Frisby, Adam]

I +1 this. XML config files drive me crazy with frequency.

> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
> bounces at lists.berlios.de] On Behalf Of Dr Scofield
> Sent: Thursday, 26 June 2008 5:27 AM
> To: opensim-dev at lists.berlios.de
> Subject: Re: [Opensim-dev] Module/Plugin Loading
> 
> 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/
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev