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
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@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
I believe no one knows where they all are. It would be quite a bit of work. :( Melanie Dahlia Trimble wrote: > 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 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
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 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
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 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
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
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
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
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
+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
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
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
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
> 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
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
Re: [Opensim-dev] Ini file(s) loading
Paul. I would think an installation wizard would be a capital idea. Only issue is it needs a "zealot" to champion it and move it forward. But, it certainly is a good idea. Charles From: Paul Fishwick To: opensim-dev@lists.berlios.de Sent: Sunday, March 8, 2009 1:48:16 PM Subject: Re: [Opensim-dev] Ini file(s) loading This makes a lot of sense, and seems how other usable packages are deployed. Is there a way to achieve it cross-platform? p Brianna wrote: > I prefer to see a 'wizard' quick interview startup like MySql for Win has > incorporated. I believe that approach is user friendly and less prone to > error than editing OpenSim.ini or the suggested multi ini's. One box check > for OSGrid would save many edits in Network, as an example. Those of us that > do this everyday are often not considerate to how formidable to a new user > OpenSim appears. After a day or so of comfort then editing ini.example to > fine tune will make for a happy camper and a hell of a lot less questions in > game or IRC. > > - Original Message - > From: "Dave Coyle" > To: > Sent: Saturday, March 07, 2009 3:07 PM > Subject: Re: [Opensim-dev] Ini file(s) loading > > > >> On 2009-03-07 10:02:55 -0500, jeffa...@gmail.com wrote: >> >>> 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. >>> >> For packaged binaries, at least in the Linux world, config files are >> going to have to be moved elsewhere during the packaging process >> anyway, so where they're located in the SVN repo and whether they're >> called *.ini or *.ini.example is largely irrelevant... for producing >> official/official-like distro packages, anyway. >> >> -Coyle >> ___ >> 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 > > -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer & Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ 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
This makes a lot of sense, and seems how other usable packages are deployed. Is there a way to achieve it cross-platform? p Brianna wrote: > I prefer to see a 'wizard' quick interview startup like MySql for Win has > incorporated. I believe that approach is user friendly and less prone to > error than editing OpenSim.ini or the suggested multi ini's. One box check > for OSGrid would save many edits in Network, as an example. Those of us that > do this everyday are often not considerate to how formidable to a new user > OpenSim appears. After a day or so of comfort then editing ini.example to > fine tune will make for a happy camper and a hell of a lot less questions in > game or IRC. > > - Original Message - > From: "Dave Coyle" > To: > Sent: Saturday, March 07, 2009 3:07 PM > Subject: Re: [Opensim-dev] Ini file(s) loading > > > >> On 2009-03-07 10:02:55 -0500, jeffa...@gmail.com wrote: >> >>> 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. >>> >> For packaged binaries, at least in the Linux world, config files are >> going to have to be moved elsewhere during the packaging process >> anyway, so where they're located in the SVN repo and whether they're >> called *.ini or *.ini.example is largely irrelevant... for producing >> official/official-like distro packages, anyway. >> >> -Coyle >> ___ >> 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 > > -- Paul Fishwick, PhD Professor and Director, Digital Arts and Sciences Programs University of Florida Computer & Information Science and Eng. Dept. Bldg. CSE, Room 301 P.O. Box 116120 Gainesville, FL 32611 Email: fishw...@cise.ufl.edu Phone: (352) 392-1414 Fax: (352) 392-1220 Web: http://www.cise.ufl.edu/~fishwick ___ 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 of the features of the app.config file section is that you can specify a file that overrides the default settings that are in the app.confiig file. In fact the app.config file itself is overriding the maching.config file. This is supported through the and tags. This model lets you download the default files but override them with files that are not part of the SVN. And if these override files can be recursive then you can have scenarios like this. The default settings config is downloaded off of SVN. I the network section is a assigned a network.config override file. If I wish to override the network section I create the network.config file. Additionally in my network.config file I can specify the fle that overrides its setting which maybe could be networkdebug.config which I use for just changing some settings I am using during debugging. This ismaybe not the best example but just trying to share the concept. I would suggest no defaults are hardcoded in the program but are externalized. At some point even the text messages in the programs should be externalized to support multiple languages. Kevin Tweedy IRC: Mystical SL: Mystical Demina -Original Message- From: Jeff Ames [mailto:jeffa...@gmail.com] Sent: Saturday, March 07, 2009 10:03 AM To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Ini file(s) loading 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 ___ 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 prefer to see a 'wizard' quick interview startup like MySql for Win has incorporated. I believe that approach is user friendly and less prone to error than editing OpenSim.ini or the suggested multi ini's. One box check for OSGrid would save many edits in Network, as an example. Those of us that do this everyday are often not considerate to how formidable to a new user OpenSim appears. After a day or so of comfort then editing ini.example to fine tune will make for a happy camper and a hell of a lot less questions in game or IRC. - Original Message - From: "Dave Coyle" To: Sent: Saturday, March 07, 2009 3:07 PM Subject: Re: [Opensim-dev] Ini file(s) loading > On 2009-03-07 10:02:55 -0500, jeffa...@gmail.com wrote: >> 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. > > For packaged binaries, at least in the Linux world, config files are > going to have to be moved elsewhere during the packaging process > anyway, so where they're located in the SVN repo and whether they're > called *.ini or *.ini.example is largely irrelevant... for producing > official/official-like distro packages, anyway. > > -Coyle > ___ > 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
On 2009-03-07 10:02:55 -0500, jeffa...@gmail.com wrote: > 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. For packaged binaries, at least in the Linux world, config files are going to have to be moved elsewhere during the packaging process anyway, so where they're located in the SVN repo and whether they're called *.ini or *.ini.example is largely irrelevant... for producing official/official-like distro packages, anyway. -Coyle ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Ini file(s) loading
I would like to know why we load the OpenSim.ini at first Working on some region server that will enable or disable things whatever the region is that they're commited to. This means I need to change code by hand now The OpenSim.ini is the standard one, then I want to disable or enable bits (different ScriptEngine, different Physics Engine) and at this time this is not a possibility So I would like to have a option that loads the OpenSim.ini at first, then loads the stuff in another folder "extended" or be able to grab additional things from the web ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Ini file(s) loading
Hi, the core of my proposal is to NOT normally edit config/* config/*.ini should be UNCOMMENTED .ini files which are the default values. If someone chooses to edit them directly, fine, their choice, but the recommended way would be to make those settings in OpenSim.ini or inimaster, leaving the config/* files untouched. This way, there would be no more *example files, no more merging and no more copying files just to make it run at all. Defaults in the code have been deemed to be impractical. Melanie Jeff Ames wrote: > 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 > ___ > 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
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 ___ 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
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
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
+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 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
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
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
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
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
Re: [Opensim-dev] Ini file(s) loading
that setup would be very helpful. --mic On Thu, Mar 5, 2009 at 5:29 AM, Melanie 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 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 wrote: >>> >>> From: Sean Hennessee >>> 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 -inidirector
Re: [Opensim-dev] Ini file(s) loading
+1 Melanie. This scenario works for me, (as a grid operator). ~Sean Melanie 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 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 wrote: >>> >>> From: Sean Hennessee >>> 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
Re: [Opensim-dev] Ini file(s) loading
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 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 wrote: >> >> From: Sean Hennessee >> 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=. >> >> So now our ini loading is a three step process: >> >> Step 1: If the -inimaster= 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=) 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 overwrot
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 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 wrote: > > From: Sean Hennessee > 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=. > > So now our ini loading is a three step process: > > Step 1: If the -inimaster= 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=) 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= 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 t
Re: [Opensim-dev] Ini file(s) loading
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 wrote: From: Sean Hennessee 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=. So now our ini loading is a three step process: Step 1: If the -inimaster= 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=) 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= 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 ___ 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=. So now our ini loading is a three step process: Step 1: If the -inimaster= 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=) 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= 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
[Opensim-dev] Ini file(s) loading
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=. So now our ini loading is a three step process: Step 1: If the -inimaster= 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=) 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= 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
