Round 2: Config changes preview

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Round 2: Config changes preview

justincc
Thanks for the feedback from round 1.  I've just uploaded a new preview as

config.preview.donotuseyet-v2

In this version I've done away with all the subdirectories.  There is now a simpler structure

config/OpenSim.ini.example
config/defaults
config/override

defaults/ is a single directory containing *.ini.defaults files.  I've collapsed many of the previously separate
*.ini.example files into fewer *.ini.defaults files (for instance, scriptengines.ini.defaults now contains all the
script engine settings and external.ini.defaults has the settings which control the data exposed externally by OpenSim).

To override the defaults, one would either

(a) copy the appropriate *.ini.defaults file into config/override/*.ini, or
(b) copy and paste the appropriate section directly into config/OpenSim.ini.  These instructions are also in READMEs in
the config directory itself.

To get OpenSim to run at all, the user still has to copy OpenSim.ini.example to OpenSim.ini (though it should be
possible to override this if config is supplied over the network).  I feel this is important to get users to give some
thought to the most crucial config settings.  Others may disagree.

In case it wasn't clear before, if you don't need to override the defaults then you don't need to make any changes.  If
a particular setting isn't present in an .ini file then there will always be a built-in default which matches that in an
*.ini.default file.

I'm also now proposing the bin/OpenSim.ini[.example] move up into bin/config/OpenSim.ini[.example].  To have OpenSim.ini
outside the config/ directory seems a little confusing to me.  Naturally, there can be a period where bin/OpenSim.ini is
still picked up.

I'm also going to reply to specific points from round 1 below.  As before, constructive feedback or approval on this is
welcomed.  I probably won't be changing this again before next week.  I'm very happy if people want to tweak the
structure, especially if some of the *.ini.defaults categorizations are wrong.  But please put any radically different
proposals in a separate config preview directory.



ANSWERS TO SPECIFIC POINTS

@Mike, DrScofield, Paul - As you can see, I have simplified the structure.  I did look at lighttpd.  One restriction I
think we have is that we can't rely on config by symlink as we're on Windows.  Also, in this structure we're overriding
defaults rather than enabling modules that didn't exist before.

@Paul - I agree with you about the ease of use of a GUI, but afaik most server projects do not come bundled with them.
Rather, they are developed and maintained separately.

@Tom, Ovi, Paul - Although a single config file is ideal, ours is getting confusing.  It's a certainty that it will grow
yet larger.  This is an attempt (picking up from MW's initial work and discussion) to find a structure that will allow
growth in the future without overwhelming newbies.  Having said that, I believe all the 95% settings should remain in
OpenSim.ini.example.  If they aren't there are the moment or the existing defaults are inappropriate then this can be
separately addressed.

@Ai - You're right about the grid settings - these will need to be brought into a config/ structure (and from what I've
previously heard, there are no objections to making the format of these conform to the Nini way of doing thigns).

@Sean - In both this structure and in the previous proposal it's quite possible just to set everything in OpenSim.ini as
can be done at the moment.  This config/ proposal is actually orthogonal to the --inimaster idea, so it should be
possible to set everything via the network if desired.).


--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: [Opensim-dev] Round 2: Config changes preview

Sean Hennessee
Does this allow for creating a single file, (e.g. mysettings.ini), in
the override directory which I can use to override all my settings,
which would essentially be a small subset of the OpenSim.ini file? (It
looks like it does, but I'd like to confirm.)

Peace,
Sean

Justin Clark-Casey wrote:

> Thanks for the feedback from round 1.  I've just uploaded a new preview as
>
> config.preview.donotuseyet-v2
>
> In this version I've done away with all the subdirectories.  There is now a simpler structure
>
> config/OpenSim.ini.example
> config/defaults
> config/override
>
> defaults/ is a single directory containing *.ini.defaults files.  I've collapsed many of the previously separate
> *.ini.example files into fewer *.ini.defaults files (for instance, scriptengines.ini.defaults now contains all the
> script engine settings and external.ini.defaults has the settings which control the data exposed externally by OpenSim).
>
> To override the defaults, one would either
>
> (a) copy the appropriate *.ini.defaults file into config/override/*.ini, or
> (b) copy and paste the appropriate section directly into config/OpenSim.ini.  These instructions are also in READMEs in
> the config directory itself.
>
> To get OpenSim to run at all, the user still has to copy OpenSim.ini.example to OpenSim.ini (though it should be
> possible to override this if config is supplied over the network).  I feel this is important to get users to give some
> thought to the most crucial config settings.  Others may disagree.
>
> In case it wasn't clear before, if you don't need to override the defaults then you don't need to make any changes.  If
> a particular setting isn't present in an .ini file then there will always be a built-in default which matches that in an
> *.ini.default file.
>
> I'm also now proposing the bin/OpenSim.ini[.example] move up into bin/config/OpenSim.ini[.example].  To have OpenSim.ini
> outside the config/ directory seems a little confusing to me.  Naturally, there can be a period where bin/OpenSim.ini is
> still picked up.
>
> I'm also going to reply to specific points from round 1 below.  As before, constructive feedback or approval on this is
> welcomed.  I probably won't be changing this again before next week.  I'm very happy if people want to tweak the
> structure, especially if some of the *.ini.defaults categorizations are wrong.  But please put any radically different
> proposals in a separate config preview directory.
>
>
>
> ANSWERS TO SPECIFIC POINTS
>
> @Mike, DrScofield, Paul - As you can see, I have simplified the structure.  I did look at lighttpd.  One restriction I
> think we have is that we can't rely on config by symlink as we're on Windows.  Also, in this structure we're overriding
> defaults rather than enabling modules that didn't exist before.
>
> @Paul - I agree with you about the ease of use of a GUI, but afaik most server projects do not come bundled with them.
> Rather, they are developed and maintained separately.
>
> @Tom, Ovi, Paul - Although a single config file is ideal, ours is getting confusing.  It's a certainty that it will grow
> yet larger.  This is an attempt (picking up from MW's initial work and discussion) to find a structure that will allow
> growth in the future without overwhelming newbies.  Having said that, I believe all the 95% settings should remain in
> OpenSim.ini.example.  If they aren't there are the moment or the existing defaults are inappropriate then this can be
> separately addressed.
>
> @Ai - You're right about the grid settings - these will need to be brought into a config/ structure (and from what I've
> previously heard, there are no objections to making the format of these conform to the Nini way of doing thigns).
>
> @Sean - In both this structure and in the previous proposal it's quite possible just to set everything in OpenSim.ini as
> can be done at the moment.  This config/ proposal is actually orthogonal to the --inimaster idea, so it should be
> possible to set everything via the network if desired.).
>
>
>  

--

Sean Hennessee
Central Computing Support
Network & Academic Computing Services
UC Irvine


... . .- -. /  .... . -. -. . ... ... . .

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: [Opensim-dev] Round 2: Config changes preview

Paul Fishwick
In reply to this post by justincc
Justin Clark-Casey wrote:
> To get OpenSim to run at all, the user still has to copy OpenSim.ini.example to OpenSim.ini (though it should be
> possible to override this if config is supplied over the network).

This may be a silly question, but is there some reason why we keep on
suggesting
that people copy OpenSim.ini.example to OpenSim.ini? Why not just make
OpenSim.ini what happens to be in OpenSim.ini.example?

-p
 

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: [hidden email]
Phone: (352) 392-1414
Fax: (352) 392-1220
Web: http://www.cise.ufl.edu/~fishwick

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: [Opensim-dev] Round 2: Config changes preview

Mike Mazur
In reply to this post by justincc
Hi,

On Sat, Mar 14, 2009 at 2:34 AM, Justin Clark-Casey
<[hidden email]> wrote:
> In this version I've done away with all the subdirectories.  There is now a simpler structure
>
> config/OpenSim.ini.example
> config/defaults
> config/override

On first glance, it's not obvious how the config files in these
directories are treated. Is the defaults/ directory scanned for valid
.ini files which are then processed?

The defaults/ directory contains scripting.ini.defaults. To enable
these settings, what should the user do? Rename to
defaults/scripting.ini, then edit? Is it necessary to copy to
override/scripting.ini and edit instead?

In my opinion, having both a directory a *.ini.defaults extensions is
one too many. Perhaps we can get away with the two directories
containing only .ini files?

config/OpenSim.ini.example
config/available/*.ini
config/override/*.ini

Or we could have just one directory which contains *.ini.defaults (or
*.ini.example) files alongside *.ini files:

config/OpenSim.ini.example
config/*.ini{,.defaults}

To enable settings, just rename <whatever>.ini.defaults to <whatever>.ini.

Mike
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: [Opensim-dev] Round 2: Config changes preview

Kyle Hamilton
In reply to this post by Paul Fishwick
because many people run their servers from inside their bin/
directory, and if it's named OpenSim.ini then any changes that are
made to that file will get overwritten (not just overridden) at the
next svn update.

That's why it was renamed to OpenSim.ini.example -- originally, it was
set to OpenSim.ini, and that problem was pretty much the number one
support issue at that time.

-Kyle H

On Fri, Mar 13, 2009 at 5:00 PM, Paul Fishwick <[hidden email]> wrote:

> Justin Clark-Casey wrote:
>> To get OpenSim to run at all, the user still has to copy OpenSim.ini.example to OpenSim.ini (though it should be
>> possible to override this if config is supplied over the network).
>
> This may be a silly question, but is there some reason why we keep on
> suggesting
> that people copy OpenSim.ini.example to OpenSim.ini? Why not just make
> OpenSim.ini what happens to be in OpenSim.ini.example?
>
> -p
>
>
> 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: [hidden email]
> Phone: (352) 392-1414
> Fax: (352) 392-1220
> Web: http://www.cise.ufl.edu/~fishwick
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: [Opensim-dev] Round 2: Config changes preview

Stefan Andersson
Some random thoughts;
 
Our config files serves three purposes, as it seems
a) specifying default values (though why on earth these are ever different from the hardcoded defaults escapes me)
b) specifying user overriding values
c) documenting available settings and their use
d) pushing changing defaults from the svn to installed instances
 
I think we need to address these concerns separately.
 
As I understand it, the config dir is so that we can
a) split humongous default config files into smaller ones
b) to be able to 'drop' module default config files into an installation without having to merge them into one big ini.
 
I think the settings can be split thrice;
1) Stuff that _must_ be reconfigured per installation : ip number, shared ports and stuff like that. (All users, should need no expertise)
2) Stuff that _can_ be reconfigured per installation. (Special installation cases, needs some knowledge)
3) Stuff that _seldom_ needs tampering. (Advanced user, special installation)
 
I would suggest we break free of the current mindset and think about how 1) could be solved differently.
 
Maybe we should say "either supply these settings on the command line, or create an OpenSim.ini file, look at OpenSim.ini.example for an example"
 
Most users would probably go a long way just by specifying the 1) params on the command line.
 
Of course, the created OpenSim.ini should need to be a bare minimum, and would probably need to change very seldom.
 
Best regards,
Stefan Andersson
Tribal Media AB



 

> Date: Sat, 14 Mar 2009 04:25:25 -0700
> From: [hidden email]
> To: [hidden email]
> CC: [hidden email]
> Subject: Re: [Opensim-dev] Round 2: Config changes preview
>
> because many people run their servers from inside their bin/
> directory, and if it's named OpenSim.ini then any changes that are
> made to that file will get overwritten (not just overridden) at the
> next svn update.
>
> That's why it was renamed to OpenSim.ini.example -- originally, it was
> set to OpenSim.ini, and that problem was pretty much the number one
> support issue at that time.
>
> -Kyle H
>
> On Fri, Mar 13, 2009 at 5:00 PM, Paul Fishwick <[hidden email]> wrote:
> > Justin Clark-Casey wrote:
> >> To get OpenSim to run at all, the user still has to copy OpenSim.ini.example to OpenSim.ini (though it should be
> >> possible to override this if config is supplied over the network).
> >
> > This may be a silly question, but is there some reason why we keep on
> > suggesting
> > that people copy OpenSim.ini.example to OpenSim.ini? Why not just make
> > OpenSim.ini what happens to be in OpenSim.ini.example?
> >
> > -p
> >
> >
> > 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: [hidden email]
> > Phone: (352) 392-1414
> > Fax: (352) 392-1220
> > Web: http://www.cise.ufl.edu/~fishwick
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-dev

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users
Reply | Threaded
Open this post in threaded view
|

Re: [Opensim-dev] Round 2: Config changes preview

me-4-2
I agree with the proposed split, at least between 1 and the rest.  
However, I doin't like the idea of having to use command line  
aruments for set #1. The result is an ugly, ugly, undocumentable  
shell script. And that's made worse because that's the one I have to  
tinker with the most to get OpenSim running.

I much prefer keeping a customized minimal OpenSim.ini file, as you  
suggested might be a possibility. In the end, I want the system to be  
able to bring itself up without my help (once it's configured  
correctly).



On Mar 14, 2009, at 6:52 AM, Stefan Andersson wrote:

> Some random thoughts;
>
> Our config files serves three purposes, as it seems
> a) specifying default values (though why on earth these are ever  
> different from the hardcoded defaults escapes me)
> b) specifying user overriding values
> c) documenting available settings and their use
> d) pushing changing defaults from the svn to installed instances
>
> I think we need to address these concerns separately.
>
> As I understand it, the config dir is so that we can
> a) split humongous default config files into smaller ones
> b) to be able to 'drop' module default config files into an  
> installation without having to merge them into one big ini.
>
> I think the settings can be split thrice;
> 1) Stuff that _must_ be reconfigured per installation : ip number,  
> shared ports and stuff like that. (All users, should need no  
> expertise)
> 2) Stuff that _can_ be reconfigured per installation. (Special  
> installation cases, needs some knowledge)
> 3) Stuff that _seldom_ needs tampering. (Advanced user, special  
> installation)
>
> I would suggest we break free of the current mindset and think  
> about how 1) could be solved differently.
>
> Maybe we should say "either supply these settings on the command  
> line, or create an OpenSim.ini file, look at OpenSim.ini.example  
> for an example"
>
> Most users would probably go a long way just by specifying the 1)  
> params on the command line.
>
> Of course, the created OpenSim.ini should need to be a bare  
> minimum, and would probably need to change very seldom.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
> > Date: Sat, 14 Mar 2009 04:25:25 -0700
> > From: [hidden email]
> > To: [hidden email]
> > CC: [hidden email]
> > Subject: Re: [Opensim-dev] Round 2: Config changes preview
> >
> > because many people run their servers from inside their bin/
> > directory, and if it's named OpenSim.ini then any changes that are
> > made to that file will get overwritten (not just overridden) at the
> > next svn update.
> >
> > That's why it was renamed to OpenSim.ini.example -- originally,  
> it was
> > set to OpenSim.ini, and that problem was pretty much the number one
> > support issue at that time.
> >
> > -Kyle H
> >
> > On Fri, Mar 13, 2009 at 5:00 PM, Paul Fishwick  
> <[hidden email]> wrote:
> > > Justin Clark-Casey wrote:
> > >> To get OpenSim to run at all, the user still has to copy  
> OpenSim.ini.example to OpenSim.ini (though it should be
> > >> possible to override this if config is supplied over the  
> network).
> > >
> > > This may be a silly question, but is there some reason why we  
> keep on
> > > suggesting
> > > that people copy OpenSim.ini.example to OpenSim.ini? Why not  
> just make
> > > OpenSim.ini what happens to be in OpenSim.ini.example?
> > >
> > > -p
> > >
> > >
> > > 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: [hidden email]
> > > Phone: (352) 392-1414
> > > Fax: (352) 392-1220
> > > Web: http://www.cise.ufl.edu/~fishwick
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > [hidden email]
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > >
> > _______________________________________________
> > Opensim-dev mailing list
> > [hidden email]
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-users mailing list
> [hidden email]
> https://lists.berlios.de/mailman/listinfo/opensim-users

_______________________________________________
Opensim-users mailing list
[hidden email]
https://lists.berlios.de/mailman/listinfo/opensim-users