[Opensim-dev] Ini file(s) loading

[Jeff Ames]

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