I vote for simplicity.. keep the defaults in the code up to date and list the available settings in the OpenSim.ini.example file *commented out* so users can know what they are and how to change them. OpenSim.ini does not update via svn so local changes should survive updates. Users who are comfortable manipulating multiple directories and config files should also be proficient enough to create shell scripts to manipulate the OpenSim.ini file for whatever conditions they require, so let's not force that pain on new users who just want to try the software out.<br>
<br><div class="gmail_quote">On Sat, Mar 14, 2009 at 10:46 AM, Mister Blue <span dir="ltr"><<a href="mailto:misterblue@misterblue.com">misterblue@misterblue.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I would like to hear from people running a large configuration of<br>
simulators and regions -- how do they want configuration?<br>
<br>
For our installation, we use a --inimaster on each simulator<br>
invocation to set up site wide settings (physics engine, etc) and then<br>
each simulator has an very small OpenSim.ini file in it's bin<br>
directory to set simulator specific configuration. We also have<br>
scripts that 'hide' the OpenSim.ini file in the Regions directory<br>
because that is a directory of information that you save when you<br>
upgrade the binaries.<br>
<br>
It's nice to have the defaults around so you know what you can tune,<br>
but it is of no use to a running simulator.<br>
<br>
I would prefer a directory of default ini files (a directory so the<br>
installation of a module can easily add a new set of parameters) and<br>
then a single ini file that the simulator reads which overrides any of<br>
the defaults. That would make administration easier since you would<br>
know what you have change from the defaults. Also, ideally, the<br>
overriding ini file should be in a 'user' directory -- not in the main<br>
bin directory so one could upgrade the binaries by just slamming the<br>
contents of a bin directory from a build on top of it.<br>
<br>
Some more two cents.<br>
<font color="#888888"><br>
-- mb<br>
</font><div><div></div><div class="h5"><br>
On Sat, Mar 14, 2009 at 6:52 AM, Stefan Andersson <<a href="mailto:stefan@tribalmedia.se">stefan@tribalmedia.se</a>> wrote:<br>
> Some random thoughts;<br>
><br>
> Our config files serves three purposes, as it seems<br>
> a) specifying default values (though why on earth these are ever different<br>
> from the hardcoded defaults escapes me)<br>
> b) specifying user overriding values<br>
> c) documenting available settings and their use<br>
> d) pushing changing defaults from the svn to installed instances<br>
><br>
> I think we need to address these concerns separately.<br>
><br>
> As I understand it, the config dir is so that we can<br>
> a) split humongous default config files into smaller ones<br>
> b) to be able to 'drop' module default config files into an installation<br>
> without having to merge them into one big ini.<br>
><br>
> I think the settings can be split thrice;<br>
> 1) Stuff that _must_ be reconfigured per installation : ip number, shared<br>
> ports and stuff like that. (All users, should need no expertise)<br>
> 2) Stuff that _can_ be reconfigured per installation. (Special installation<br>
> cases, needs some knowledge)<br>
> 3) Stuff that _seldom_ needs tampering. (Advanced user, special<br>
> installation)<br>
><br>
> I would suggest we break free of the current mindset and think about how<br>
> 1) could be solved differently.<br>
><br>
> Maybe we should say "either supply these settings on the command line, or<br>
> create an OpenSim.ini file, look at OpenSim.ini.example for an example"<br>
><br>
> Most users would probably go a long way just by specifying the 1) params on<br>
> the command line.<br>
><br>
> Of course, the created OpenSim.ini should need to be a bare minimum, and<br>
> would probably need to change very seldom.<br>
><br>
> Best regards,<br>
> Stefan Andersson<br>
> Tribal Media AB<br>
><br>
><br>
><br>
><br>
>> Date: Sat, 14 Mar 2009 04:25:25 -0700<br>
>> From: <a href="mailto:aerowolf@gmail.com">aerowolf@gmail.com</a><br>
>> To: <a href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
>> CC: <a href="mailto:opensim-users@lists.berlios.de">opensim-users@lists.berlios.de</a><br>
>> Subject: Re: [Opensim-dev] Round 2: Config changes preview<br>
>><br>
>> because many people run their servers from inside their bin/<br>
>> directory, and if it's named OpenSim.ini then any changes that are<br>
>> made to that file will get overwritten (not just overridden) at the<br>
>> next svn update.<br>
>><br>
>> That's why it was renamed to OpenSim.ini.example -- originally, it was<br>
>> set to OpenSim.ini, and that problem was pretty much the number one<br>
>> support issue at that time.<br>
>><br>
>> -Kyle H<br>
>><br>
>> On Fri, Mar 13, 2009 at 5:00 PM, Paul Fishwick <<a href="mailto:fishwick@cise.ufl.edu">fishwick@cise.ufl.edu</a>><br>
>> wrote:<br>
>> > Justin Clark-Casey wrote:<br>
>> >> To get OpenSim to run at all, the user still has to copy<br>
>> >> OpenSim.ini.example to OpenSim.ini (though it should be<br>
>> >> possible to override this if config is supplied over the network).<br>
>> ><br>
>> > This may be a silly question, but is there some reason why we keep on<br>
>> > suggesting<br>
>> > that people copy OpenSim.ini.example to OpenSim.ini? Why not just make<br>
>> > OpenSim.ini what happens to be in OpenSim.ini.example?<br>
>> ><br>
>> > -p<br>
>> ><br>
>> ><br>
>> > Paul Fishwick, PhD<br>
>> > Professor and Director, Digital Arts and Sciences Programs<br>
>> > University of Florida<br>
>> > Computer & Information Science and Eng. Dept.<br>
>> > Bldg. CSE, Room 301<br>
>> > P.O. Box 116120<br>
>> > Gainesville, FL 32611<br>
>> > Email: <a href="mailto:fishwick@cise.ufl.edu">fishwick@cise.ufl.edu</a><br>
>> > Phone: (352) 392-1414<br>
>> > Fax: (352) 392-1220<br>
>> > Web: <a href="http://www.cise.ufl.edu/~fishwick" target="_blank">http://www.cise.ufl.edu/~fishwick</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > Opensim-dev mailing list<br>
>> > <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> > <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>> ><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>