I like the idea of splitting up the ini and putting it in config/*, but having an overriding opensim.ini will be confusing to the noob. I think that there will be a new FAQ - "Where do I edit the configuration? in bin or config? ;-)
Just splitting up the file and putting it in config, with all the comments, would help. And for the SVN update - that is a problem with any modifications to the tree, not just config. That's what backups are for. I guess a simple backup/diff tool for config would be a quick solution... I also like the idea of a better, more extensive (and extensible) wizard, either on startup or as a standalone - run opensimconfig first, answer a few questions. done. Kurt Justin Clark-Casey wrote: > Frisby, Adam wrote: > >> I did wonder why we started forcing users to have an opensim.ini. The >> previous 'use defaults' made more sense to me. >> > > Unfortunately, the hardcoded defaults had become out of alignment with sane > default settings, causing various degrees of > user distress. > > Any time where settings exist in two places there is a big risk of them > getting out of sync. I would argue that modules > should fail on startup rather than contain hardcoded defaults. External > files such as OpenSim.ini.example (or > config/*.ini) are better in that they provide explanatory comments and make > available settings user visible. > > >> Adam >> >> >>> -----Original Message----- >>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- >>> boun...@lists.berlios.de] On Behalf Of Jeff Ames >>> Sent: Thursday, 5 March 2009 7:20 PM >>> To: opensim-dev@lists.berlios.de >>> Subject: Re: [Opensim-dev] Ini file(s) loading >>> >>> Melanie wrote: >>> >>>> read [the config directory] first >>>> then read the inimaster >>>> then read the inifile >>>> >>> If I understand this correctly, the config/*.ini files would be >>> essentially read-only, and all local changes would be made to the >>> inimaster or OpenSim.ini. But then OpenSim.ini is not broken up, and >>> it may be confusing to users why there are two sets of config files. >>> >>> Is this just due to OpenSim's current behavior of requiring an .ini >>> file to be present? Currently the default values for all settings >>> exist in the code itself and in the .ini.example file (itself an >>> unfortunate duplication, but that's another topic). Instead of >>> requiring that an .ini be present, we could simply use the default >>> values in the code if there is no .ini. This would also have the >>> pleasant side effect of matching the behavior when an empty .ini file >>> is present. >>> >>> Then we could break up and move OpenSim.ini.example entirely to >>> config/*.ini.example files, and when the user wants to change a value, >>> create foo.ini based on foo.ini.example (copying the whole file if >>> they want everything, or only adding the options they want to >>> explicitly set). >>> >>> Then I guees the load order would be: >>> - read inimaster (if present) >>> - read config/*.ini (if present) >>> - use defaults in code for anything not set >>> >>> I think this would also avoid the merging problem, if users only add >>> options they're explicitly setting to the *.ini files. It would also >>> remove the annoyance of having to copy the .ini.example file over >>> every time on a new install. >>> >>> Jeff >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > > -- Kurt Taylor (Kurt Stringer) _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
