[Opensim-dev] Module/Plugin Loading

Thu Jun 26 13:26:49 UTC 2008

Personally, I have no problem with xml config files; the only thing is, I usually want to be able to

a) partition the config file (but having a 'real' "[Network]" grouping thingy in an ini works just as well
b) specify several instances
c) nest levels, when needed (related to b)

But hell, as always, we should go for the simplest, readliest, solution that does what we want it to.

And no, I've long forgotten the Nini case that bothered me, so I'm justa goinga shutta uppa'bout it. (until I remember)
Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ 

> Date: Thu, 26 Jun 2008 08:39:02 -0400> From: adam at deepthink.com.au> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] Module/Plugin Loading> > 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> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080626/55936de1/attachment-0001.html>