Re: [Opensim-dev] Ini file(s) loading
Melanie wrote: And that brings us full circle to my proposal. There is much sense in a set of files that are used as defaults, and then overriding settings in specific configuration files. +1 on that proposal. DrS/dirk -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
Is there any reason why we wouldn't want to update the defaults in the code to sane values? On Fri, Mar 6, 2009 at 1:57 AM, Melanie mela...@t-data.com wrote: We did that because the hardcoded defaults won't work anymore. They are different fromt he OpenSim.ini.example values. However, my proposal provides a sane mechanism to provide external defaults, while not requiring user action at all. Melanie 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. 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 ___ 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
Re: [Opensim-dev] Ini file(s) loading
Sane values are desperately needed. I deal with many new users every week, in game and on forums. Most are x-pat SL content creators that are on top of that side but get hyper confused with an OpenSim binary. Many will tough it out and get an instance started but too many give up in frustration. Lately my improved technique is to have them fetch the OpenSim.ini from OSGrid dl, that at least gets past the first hurdles sanely. Or if standalone, use that .ini with very minimal edit. I suggest anyone here open ini.example and look at it from a new user semi technical viewpoint. - Original Message - From: Dahlia Trimble To: opensim-dev@lists.berlios.de Sent: Tuesday, March 10, 2009 11:21 PM Subject: Re: [Opensim-dev] Ini file(s) loading Is there any reason why we wouldn't want to update the defaults in the code to sane values? On Fri, Mar 6, 2009 at 1:57 AM, Melanie mela...@t-data.com wrote: We did that because the hardcoded defaults won't work anymore. They are different fromt he OpenSim.ini.example values. However, my proposal provides a sane mechanism to provide external defaults, while not requiring user action at all. Melanie 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. 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 ___ 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
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@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
Built-in settings were pretty much abolished because it was found that it's not possible/feasible to keep them sane. 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. 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@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
Re: [Opensim-dev] Ini file(s) loading
Actually, I thought it supported my point very well. ;-) I was not suggesting that the split ini in config be the only config option - I still like to override idea. But by default, users would edit the config/*ini, this does not stop a multi-region grid operator from syncing 20 override ini files to the bin of their regions. My point was that there just should not be 2 places by default, one with default values and one with the overriding used values - that will just severely confuse the situation. Kurt Melanie wrote: And that brings us full circle to my proposal. There is much sense in a set of files that are used as defaults, and then overriding settings in specific configuration files. Melanie Sean Hennessee wrote: I am one of those people that run trunk and update fairly often on 9 different OpenSim servers. I suspect I always will be. Having to manually merge two huge ini files, on 9 different servers, is a major pain. It would be even worse if I had to merge 6 or 8 different medium sized ini files on each of my 9 servers. Where they are located is not important to me, but I really would like to have an SVN new set of ini files, (or one ini file), with all the latest changes that is read first, and a way for me to have a small ini file that I can use for my specific settings which will override the default ini settings. That would make my life much much easier. Peace, Sean Jeff Ames wrote: 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... Just have config/*.ini and let conflicts happen as they come? I kinda agree... If you're updating some application from version 1.0 to 2.0, you expect to have to merge your config changes. I imagine part of the merge problem is just that people are running trunk and updating all the time rather than using the (too infrequent?) tagged releases. I'm +1 on just using config/*.ini directly. Jeff ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Sean Hennessee mailto:s...@uci.edu http://www.nacs.uci.edu/~sean Central Computing Support Network Academic Computing Services UC Irvine (949)824-8225 Office (949)293-5224 Cell ... . .- -. / . -. -. . ... ... . . ___ 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
Re: [Opensim-dev] Ini file(s) loading
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... Just have config/*.ini and let conflicts happen as they come? I kinda agree... If you're updating some application from version 1.0 to 2.0, you expect to have to merge your config changes. I imagine part of the merge problem is just that people are running trunk and updating all the time rather than using the (too infrequent?) tagged releases. I'm +1 on just using config/*.ini directly. Jeff ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
How about splitting to normal ini file and advanced ini file? In the normal ini file you would have those parameters which 95% of the people change and rest can be stuffed to advanced ini file. - Tommi ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
I am one of those people that run trunk and update fairly often on 9 different OpenSim servers. I suspect I always will be. Having to manually merge two huge ini files, on 9 different servers, is a major pain. It would be even worse if I had to merge 6 or 8 different medium sized ini files on each of my 9 servers. Where they are located is not important to me, but I really would like to have an SVN new set of ini files, (or one ini file), with all the latest changes that is read first, and a way for me to have a small ini file that I can use for my specific settings which will override the default ini settings. That would make my life much much easier. Peace, Sean Jeff Ames wrote: 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... Just have config/*.ini and let conflicts happen as they come? I kinda agree... If you're updating some application from version 1.0 to 2.0, you expect to have to merge your config changes. I imagine part of the merge problem is just that people are running trunk and updating all the time rather than using the (too infrequent?) tagged releases. I'm +1 on just using config/*.ini directly. Jeff ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Sean Hennessee mailto:s...@uci.edu http://www.nacs.uci.edu/~sean Central Computing Support Network Academic Computing Services UC Irvine (949)824-8225 Office (949)293-5224 Cell ... . .- -. / . -. -. . ... ... . . ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
+1 Melanie! ... ... whoa, deja vu! :) ~Sean Melanie wrote: And that brings us full circle to my proposal. There is much sense in a set of files that are used as defaults, and then overriding settings in specific configuration files. Melanie Sean Hennessee wrote: I am one of those people that run trunk and update fairly often on 9 different OpenSim servers. I suspect I always will be. Having to manually merge two huge ini files, on 9 different servers, is a major pain. It would be even worse if I had to merge 6 or 8 different medium sized ini files on each of my 9 servers. Where they are located is not important to me, but I really would like to have an SVN new set of ini files, (or one ini file), with all the latest changes that is read first, and a way for me to have a small ini file that I can use for my specific settings which will override the default ini settings. That would make my life much much easier. Peace, Sean Jeff Ames wrote: 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... Just have config/*.ini and let conflicts happen as they come? I kinda agree... If you're updating some application from version 1.0 to 2.0, you expect to have to merge your config changes. I imagine part of the merge problem is just that people are running trunk and updating all the time rather than using the (too infrequent?) tagged releases. I'm +1 on just using config/*.ini directly. Jeff -- Sean Hennessee Central Computing Support Network Academic Computing Services UC Irvine ... . .- -. / . -. -. . ... ... . . ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
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. 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@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
We did that because the hardcoded defaults won't work anymore. They are different fromt he OpenSim.ini.example values. However, my proposal provides a sane mechanism to provide external defaults, while not requiring user action at all. Melanie 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. 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
+1 for me. it will ease all the maintenance and lot of redundnat questions related to the configuration we got often in #opensim On Fri, Mar 6, 2009 at 9:57 AM, Melanie mela...@t-data.com wrote: We did that because the hardcoded defaults won't work anymore. They are different fromt he OpenSim.ini.example values. However, my proposal provides a sane mechanism to provide external defaults, while not requiring user action at all. Melanie 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. 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- http://K-grid.com Just be cause it's Kool ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
I like it - no more merging, defaults split up between files for manageability, no more hunt the ini in the mammoth bin directory. Defaults are readable - if you got rid of the example file or the need for an ini at all you'd have to dig through code to figure out what the defaults were. You still get plenty of control over options via the master (if you use a master), and then individual differences in local instances. +1 -Original Message- From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Melanie Sent: 06 March 2009 08:56 To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Ini file(s) loading Hi, Jeff Ames wrote: Melanie wrote: read [the config directory] first then read the inimaster then read the inifile This is because the config/* files would hold the defaults, they must be read first. [...] 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). 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. 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! 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 See above, this won't serve the users' needs. In your scenario, if the config/*.example changes, they'd still need to merge. What I propose, to reiterate, is this: Break up Opensim.ini.example into config/*.ini. Uncomment all the options so they serve as defaults. Remove the explicit requirement for an ini file. This way, sitewide changes from the provided defaults go to inimaster, and machine/instance settings go to opensim.ini. The files in config/ can remain unchanged and can be updated on every svn update, without manual merging. Of course, many other use cases are possible, including modifications to config/*.ini if desired, or omitting either configuration source. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.0.237 / Virus Database: 270.11.5/1977 - Release Date: 03/05/09 19:32:00 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
Melanie wrote: Hi, Jeff Ames wrote: Melanie wrote: read [the config directory] first then read the inimaster then read the inifile This is because the config/* files would hold the defaults, they must be read first. [...] 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). 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. If/when we split up OpenSim,ini then we do largely need to get away from .example files - renaming lots of config/*.ini.example files is obviously a no go. If we get rid of OpenSim.ini entirely, then when a new user wants to change their storage/network settings (which I suspect pretty much everyone does sooner or later), they will either (a) Follow some instructions to copy config/storage.ini to OpenSim.ini and then tweak it or (b) Change config/storage.ini directly Even if we encouraged (a), I think that realistically people will just end up doing (b). If config/storage.ini ends up in SVN, then when it changes we will wreck their configuration. I think that overriding default storage settings would also be confusing to users. So I would argue that we should retain mandatory OpenSim.ini/OpenSim.ini.example just for storage and other absolutely basic settings (e.g. gridmode). This would also mean that many users wouldn't need to worry at all about the contents of config/ I acknowledge this may be a pita for those supplying configuration purely over the network, though maybe there could be some extra setting that switches off a mandatory OpenSim.ini in these situations. 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! 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 See above, this won't serve the users' needs. In your scenario, if the config/*.example changes, they'd still need to merge. What I propose, to reiterate, is this: Break up Opensim.ini.example into config/*.ini. Uncomment all the options so they serve as defaults. Remove the explicit requirement for an ini file. This way, sitewide changes from the provided defaults go to inimaster, and machine/instance settings go to opensim.ini. The files in config/ can remain unchanged and can be updated on every svn update, without manual merging. Of course, many other use cases are possible, including modifications to config/*.ini if desired, or omitting either configuration source. Melanie ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
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 -- justincc Justin Clark-Casey http://justincc.wordpress.com ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
that setup would be very helpful. --mic On Thu, Mar 5, 2009 at 5:29 AM, Melanie mela...@t-data.com wrote: To me, what would make the most sense is this: - break up the Opensim.ini.example into chunks, and but them into a config directory - read this directory first - then read the inimaster - then read the inifile - this means that new opensim.ini options would, in the future, appear in these defaults files, which could be left unchanged in most cases, therefore adding new options is easy on grid operators, no more merging Melanie Mic Bowman wrote: fwiw... we use a shared inimaster as the base for the configuration of simulators running on multiple servers. then each simulator has a very small opensim.ini, typically just to configure the network ports and the storage parameters. that is, the local opensim.ini overwrites the shared values in the inimaster. bulk changes are easy (just change the inimaster) and customizations are very small. --mic On Wed, Mar 4, 2009 at 4:14 PM, MW michaelwr...@yahoo.co.uk wrote: Well I only inserted the loading from the config folder, inbetween the two existing steps. It has always been that the 'masterini' file was loaded first (if one was given as a argument) and then opensim.ini (or whatever was set with -inifile) was loaded. The original idea behind the master being that it could be a master file for say a whole grid, while each one had some local changes in the bin\opensim.ini. But I agree that it can be confusing, especially with the chosen names. So maybe we do need to rethink that. --- On Wed, 4/3/09, Sean Hennessee s...@uci.edu wrote: From: Sean Hennessee s...@uci.edu Subject: Re: [Opensim-dev] Ini file(s) loading To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de Date: Wednesday, 4 March, 2009, 10:37 PM Yay!! +1 Updating ini files is often a pain. This is an excellent step in the right direction. In this scenario, my suggestion/preference would be to have the bin/config directory contain all the SVN default values, (any number of files), with NO bin/opensim.ini file present by default. Then I could create a bin/opensim.ini file as a very small set of overriding values specific to my grids. The inimaster really wouldn't be used since it would always get overwritten. Below are my suggestions instead of using this parsing order. Looking at the three steps, I'm not sure I understand the logic of the order chosen. The 'inimaster' sounds like it should be the master and not ever be overwritten, i.e. it should be parsed last. To keep things at least more familiar to what they are now, I would prefer that the bin/opensim.ini file be the same one it is now, the default one that comes with the SVN, and parsed first. The bin/config directory would then be the second set of ini's parsed to allow my multiple ini files to override the standard default. Then, if one specifically identifies an inimaster, that should override everything else, especially since you have to specify it on the command line. My line of thinking is that if you are specifically saying use this inimaster on the command line that would mean you really want to use it only, as in a testing scenario without having to worry about default/other overrides. IIRC other linux/server type programs, like sendmail, behave similar to this. It might also be nice to have an include type of statement in the ini file/url allowing you to reference files/urls without having them in a special location as well as specifying the order you want them read instead of having to make them alphabetical for order. Anyway, my OS$2. And thanks for working on this! Peace, Sean MW wrote: Last week, I added the ability for opensim to search a folder for ini files and load (and merge together) all of those files. By default it will look for the folder 'bin\config' and search that for .ini files. The folder it searches can be changed by using the command line argument -inidirectory=path. So now our ini loading is a three step process: Step 1: If the -inimaster=filepath or url command line argument was used, load that file/url. Step 2: Then check if the config directory (default 'bin\config' or one set by -inidirectory=path) exists and search that folder for ini files and load them. They are merged on top of the inimaster file. So any duplicate entries will be overwrote. Step 3: Load the inifile, which by default is 'bin\opensim.ini' but can be changed by using the -inifile=filepath or url command line argument. This again is merged on top of all previous settings so will overwrite the older (from previous steps) settings. Now the question is how we should set things up in SVN as the default. It would be nice to split up the opensim.ini, into multiple ini files in the config directory. And then just have a small opensim.ini that contains the values likely to change ofter, like network settings etc. But because
Re: [Opensim-dev] Ini file(s) loading
I did wonder why we started forcing users to have an opensim.ini. The previous 'use defaults' made more sense to me. 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
Re: [Opensim-dev] Ini file(s) loading
Yay!! +1 Updating ini files is often a pain. This is an excellent step in the right direction. In this scenario, my suggestion/preference would be to have the bin/config directory contain all the SVN default values, (any number of files), with NO bin/opensim.ini file present by default. Then I could create a bin/opensim.ini file as a very small set of overriding values specific to my grids. The inimaster really wouldn't be used since it would always get overwritten. Below are my suggestions instead of using this parsing order. Looking at the three steps, I'm not sure I understand the logic of the order chosen. The 'inimaster' sounds like it should be the "master" and not ever be overwritten, i.e. it should be parsed last. To keep things at least more familiar to what they are now, I would prefer that the bin/opensim.ini file be the same one it is now, the default one that comes with the SVN, and parsed first. The bin/config directory would then be the second set of ini's parsed to allow my multiple ini files to override the standard default. Then, if one specifically identifies an inimaster, that should override everything else, especially since you have to specify it on the command line. My line of thinking is that if you are specifically saying "use this inimaster" on the command line that would mean you really want to use it only, as in a testing scenario without having to worry about default/other overrides. IIRC other linux/server type programs, like sendmail, behave similar to this. It might also be nice to have an "include" type of statement in the ini file/url allowing you to reference files/urls without having them in a special location as well as specifying the order you want them read instead of having to make them alphabetical for order. Anyway, my OS$2. And thanks for working on this! Peace, Sean MW wrote: Last week, I added the ability for opensim to search a folder for ini files and load (and merge together) all of those files. By default it will look for the folder 'bin\config' and search that for .ini files. The folder it searches can be changed by using the command line argument -inidirectory=path. So now our ini loading is a three step process: Step 1: If the -inimaster=filepath or url command line argument was used, load that file/url. Step 2: Then check if the config directory (default 'bin\config' or one set by -inidirectory=path) exists and search that folder for ini files and load them. They are merged on top of the inimaster file. So any duplicate entries will be overwrote. Step 3: Load the inifile, which by default is 'bin\opensim.ini' but can be changed by using the -inifile=filepath or url command line argument. This again is merged on top of all previous settings so will overwrite the older (from previous steps) settings. Now the question is how we should set things up in SVN as the default. It would be nice to split up the opensim.ini, into multiple ini files in the config directory. And then just have a small opensim.ini that contains the values likely to change ofter, like network settings etc. But because the config directory overwrites the master file, this could cause problems for people who have already set things up for using a master file/url. Of course the simple solution for them would be just to delete the config directory. But anyway what does everyone think? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Sean Hennessee Central Computing Support Network Academic Computing Services UC Irvine ... . .- -. / . -. -. . ... ... . . ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
fwiw... we use a shared inimaster as the base for the configuration of simulators running on multiple servers. then each simulator has a very small opensim.ini, typically just to configure the network ports and the storage parameters. that is, the local opensim.ini overwrites the shared values in the inimaster. bulk changes are easy (just change the inimaster) and customizations are very small. --mic On Wed, Mar 4, 2009 at 4:14 PM, MW michaelwr...@yahoo.co.uk wrote: Well I only inserted the loading from the config folder, inbetween the two existing steps. It has always been that the 'masterini' file was loaded first (if one was given as a argument) and then opensim.ini (or whatever was set with -inifile) was loaded. The original idea behind the master being that it could be a master file for say a whole grid, while each one had some local changes in the bin\opensim.ini. But I agree that it can be confusing, especially with the chosen names. So maybe we do need to rethink that. --- On Wed, 4/3/09, Sean Hennessee s...@uci.edu wrote: From: Sean Hennessee s...@uci.edu Subject: Re: [Opensim-dev] Ini file(s) loading To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de Date: Wednesday, 4 March, 2009, 10:37 PM Yay!! +1 Updating ini files is often a pain. This is an excellent step in the right direction. In this scenario, my suggestion/preference would be to have the bin/config directory contain all the SVN default values, (any number of files), with NO bin/opensim.ini file present by default. Then I could create a bin/opensim.ini file as a very small set of overriding values specific to my grids. The inimaster really wouldn't be used since it would always get overwritten. Below are my suggestions instead of using this parsing order. Looking at the three steps, I'm not sure I understand the logic of the order chosen. The 'inimaster' sounds like it should be the master and not ever be overwritten, i.e. it should be parsed last. To keep things at least more familiar to what they are now, I would prefer that the bin/opensim.ini file be the same one it is now, the default one that comes with the SVN, and parsed first. The bin/config directory would then be the second set of ini's parsed to allow my multiple ini files to override the standard default. Then, if one specifically identifies an inimaster, that should override everything else, especially since you have to specify it on the command line. My line of thinking is that if you are specifically saying use this inimaster on the command line that would mean you really want to use it only, as in a testing scenario without having to worry about default/other overrides. IIRC other linux/server type programs, like sendmail, behave similar to this. It might also be nice to have an include type of statement in the ini file/url allowing you to reference files/urls without having them in a special location as well as specifying the order you want them read instead of having to make them alphabetical for order. Anyway, my OS$2. And thanks for working on this! Peace, Sean MW wrote: Last week, I added the ability for opensim to search a folder for ini files and load (and merge together) all of those files. By default it will look for the folder 'bin\config' and search that for .ini files. The folder it searches can be changed by using the command line argument -inidirectory=path. So now our ini loading is a three step process: Step 1: If the -inimaster=filepath or url command line argument was used, load that file/url. Step 2: Then check if the config directory (default 'bin\config' or one set by -inidirectory=path) exists and search that folder for ini files and load them. They are merged on top of the inimaster file. So any duplicate entries will be overwrote. Step 3: Load the inifile, which by default is 'bin\opensim.ini' but can be changed by using the -inifile=filepath or url command line argument. This again is merged on top of all previous settings so will overwrite the older (from previous steps) settings. Now the question is how we should set things up in SVN as the default. It would be nice to split up the opensim.ini, into multiple ini files in the config directory. And then just have a small opensim.ini that contains the values likely to change ofter, like network settings etc. But because the config directory overwrites the master file, this could cause problems for people who have already set things up for using a master file/url. Of course the simple solution for them would be just to delete the config directory. But anyway what does everyone think? ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev -- Sean Hennessee Central Computing Support Network Academic Computing Services UC Irvine
