[Opensim-dev] Ini file(s) loading

[Justin Clark-Casey]

Melanie wrote:
> Built-in settings were pretty much abolished because it was found 
> that it's not possible/feasible to keep them sane.

I disagree.  It's true that settings were not being kept in sync before but this does not mean that it isn't 
possible/feasible.  As long as someone is watching patches go in then it is quite easy to catch instances where 
synchronization has been broken.

It's very easy to rectify this in the current code.  These values are easy to track down with a grep.  And I see Dahlia 
has already fixed up some.  I was wrong myself in thinking this was so bad earlier on.

> I think that using an additional OpenSim.ini file is not too steep a 
> learning curve, and that we should not design to the lowest denominator.

I have no idea what you mean by 'lowest denominator'.  As far as I'm concerned, there are just users of our software. 
We should try to make it as easy for them to use as possible and make it hard for them to muck it up.

I think that having two live *.ini files where the user is expected to override the values in config/*.ini with 
OpenSim.ini is confusing.  It should be possible for sophisticated users to do this but it should not be our default 
configuration strategy.

> 
> A config override hierarchy is, IMHO, just the ticket. Soon as I 
> find some time in the chaos of moving house, I wanted to change all 
> three options to accept either a single file, a directory, or a URI. 
> That provides the greatest flexibility and would allow them to copy 
> config/*.ini to local/*.ini, or somesuch, and edit them there.
> 
> Melanie
> 
> Justin Clark-Casey wrote:
>> Jeff Ames wrote:
>>> One nice thing about merge conflicts is that it tells you right away
>>> if a variable you've changed has been modified (e.g., the variable
>>> name changed), so you can correct it immediately instead of wondering
>>> why feature X isn't working any more.  But I guess there'd be a lot of
>>> false alarms, if comments near the variable or the variable's default
>>> value change in SVN.
>> Yeah, it's a nice idea but I think those false alarms are the problem.  The first time that a conflict happens the 
>> user's installation will probably stop working due to conflict markers in the .ini file.  I have to predict that people 
>> will change these .ini files directly without reading documentation first.
>>
>> Another solution I would propose is to name these files *.ini.example in SVN (or *.ini-dist a la PHP) and go back to 
>> using built-in defaults that match these files.  I know this goes against what I said before about duplicating settings, 
>> but I couldn't think up a good solution that uses live .ini files and meets my particular concerns.  If a user wants to 
>> override the built in defaults then they copy *.ini.dist to *.ini or add to OpenSim.ini.
>>
>> At least this way, sophisticated grid operators tracking SVN might be happy since they no longer need to merge *.ini 
>> files.  And individual users using OpenSim in standalone or hypergrid modes will also be happy since it will be clear 
>> how to override built-in defaults and they won't suffer merge conflicts if they are tracking SVN.  I still think that 
>> overriding settings only through OpenSim.ini is too complicated compared to a simple copy and edit that keeps the 
>> setting in a single place.
>>
>> This solution would require that we have more discipline than before in keeping *.ini.dist files aligned with built-in 
>> settings.
>>
>>> One final idea: instead of config/*.ini.example as I originally
>>> suggested, have a config/ directory (empty) and config.example/*.ini.
>>> Then users can copy config.example/foo.ini to config/foo.ini and make
>>> changes there.  Essentially the same idea, but copying files instead
>>> of renaming them.  Just trying to avoid having to have users keep
>>> their modifications in a monolithic .ini file.
>>>
>>> Jeff
>>> _______________________________________________
>>> 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
> 


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com