[Opensim-dev] Ini file(s) loading

[Mystical Demina]

One of the features of the app.config file <appsettings> section is that you
can specify a file that overrides the default settings that are in the
app.confiig file.  In fact the app.config file itself is overriding the
maching.config file.  This is supported through the <add> and <remove> tags.


This model lets you download the default files but override them with files
that are not part of the SVN.  And if these override files can be recursive
then you can have scenarios like this.  The default settings config is
downloaded off of SVN.  I the network section is a assigned a network.config
override file.  If I wish to override the network section I create the
network.config file.  Additionally in my network.config file I can specify
the fle that overrides its setting which maybe could be networkdebug.config
which I use for just changing some settings I am using during debugging.
This ismaybe not the best example but just trying to share the concept.

I would suggest no defaults are hardcoded in the program but are
externalized.  At some point even the text messages in the programs should
be externalized to support multiple languages.

Kevin Tweedy
IRC: Mystical
SL: Mystical Demina

-----Original Message-----
From: Jeff Ames [mailto:jeffames at gmail.com] 
Sent: Saturday, March 07, 2009 10:03 AM
To: opensim-dev at lists.berlios.de
Subject: Re: [Opensim-dev] Ini file(s) loading

Melanie wrote:
> I was suggesting to get away from *.example files. Instead, I am
> proposing to break up OpenSim.ini into *.ini files that provide the
> defaults. The in-code defaults are a requirement of Nini, but they
> are not functional, just ignore that they're there. The requirement
> for an OpenSim.ini file in code needs to be dropped, of course.

It seems like our proposals are actually fairly similar.  There has to
be some set of broken-up files with the .ini settings, which the
developers can update in SVN without fear of causing merge conflicts
for users.  In your proposal, these are config/*.ini.  In mine,
config/*.ini.example.

Then there needs to be a place for users to make changes to the
default config.  Yours is bin/OpenSim.ini, mine is config/*.ini.

> That is why the config directory needs to be read first - it
> provides the defaults! Inimaster would be rendered useless by the
> load order you're proposing!

I believe (at least I meant) that inimaster would function the same as
it does now.  If inimaster says use ODE, then unless the user's local
config explicitly overrides that, the sim would use ODE.  If neither
the inimaster or the local config say anything, OpenSim reverts to the
default basicphysics.

> In your scenario, if the config/*.example changes, they'd still need
> to merge.

If they copy the foo.ini.example to foo.ini, and then foo.ini.example
changes, then yes, they would have to find a way to integrate those
changes in foo.ini.  If they only add what they're explicitly changing
to foo.ini, then the amount of merging would be reduced quite a bit.

But unless I misunderstand what you mean by the merging problem,
there's no way to totally avoid it.  The config files will change, and
users will have to integrate those changes somehow.  (Can we do
migrations for .ini files?)

I also think that having defaults in the code is useful, so that
external .ini files are not required.  At the least, I'd like to have
a system where you could check out from SVN, build, and run, without
having to copy files around.

Getting rid of the *.example files would be great, if we can.  I
believe that the original reason for adding them wasn't avoiding merge
conflicts with users' configs (though that's nice), but to avoid
accidental commits of developers' configs to SVN.

For a binary release, I think having only user-editable config/*.ini
files would make the most sense.  But maybe how we handle .ini files
in SVN is necessarily more complicated.

One option to remove the duplication, as well as avoiding these merge
conflicts, may be to keep the defaults in the code and generate the
config files programmatically, but that would likely take a bit of
tweaking, as I don't think Nini has any support for comments.

Jeff