[Opensim-dev] Globally avaibability of config options (?)

[Stefan Andersson]

I just suggested on the #opensim-dev chat that we let the IModule interface expose two methods;
one, to register the modules need of config parameters, and one to fetch them
This would be done thru the generic Nini config sources; ideally, the module wouldn't know how the core choose to persist the settings.
 
/Stefan



> Date: Fri, 19 Oct 2007 19:57:03 +0200> From: Gerhard.Duennebeil at arcs.ac.at> To: opensim-dev at lists.berlios.de> Subject: AW: [Opensim-dev] Globally avaibability of config options (?)> > > > >>This said, it's a bad thing to pass a poorly typed config collection around the system; better to be explicit and specific about what each component >>needs to know to do its work, one you get down to actually instantiate something./Stefan> > I agree for paramaters that are strongly related to the task of a certain piece of code.> If you need to know about some parameters to understand it's working -- pass it as a parameter.> I even agree to the point that a piece of code should reasonable work, if no ini-file is present.> > If it's about some other settings (like e.g. which path to write files to, that are only used to debug the code, and no, this is no logging output)> or other parameters like some that influence the internal accuracy, I don't agree.> 1. There might be a hole lot of these settings.> 2. Thinking about a layered architecture that allows modules to be plugged and exchanged, there might be parameters that are different for each implementation. How to pass those through parameters once the interface is stable?> > So I stick with the ini-file approach here. The only question is, how to do it best?> > Gerhard> > -----Ursprüngliche Nachricht-----> Von: opensim-dev-bounces at lists.berlios.de im Auftrag von Stefan Andersson> Gesendet: Fr 10/19/2007 5:46> An: opensim-dev at lists.berlios.de> Betreff: Re: [Opensim-dev] Globally avaibability of config options (?)> > All your points are good and valid. We need to get our config and directory shit together.> > We're trying to move to Nini configuration library for configuration settings.> > Nini is an excellent framework for combining different types of settings, and supports cascading and defaults. I think you will find it gives you what you're asking for.> > This said, it's a bad thing to pass a poorly typed config collection around the system; better to be explicit and specific about what each component needs to know to do its work, one you get down to actually instantiate something./Stefan> > > Date: Fri, 19 Oct 2007 07:18:46 -0700From: mic.bowman at intel.comTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] Globally avaibability of config options (?)> > > > what about a common class that reads the same config file that each component can instantiate? similar to the proposal for logging.> > personally, i'd like to see the following objectives for config:> * single file OR single directory for all configuration information> - single directory assumes consistent file naming conventions and common syntax across the files (to the extent its possible)> * consistent method for overriding config through command line options> * ability to set all paths through the config files (move a bunch of the immediate strings into config vars)> - eg location of the asset/library initialization files, region/estate settings file names, default terrain> > right now configuration includes multiple formats (xml for regions & estatesettings & asset/library initialization, ini format for high level sim config), multiple directories (off bin including regions, script engines, terrain filters, etc), multiple naming conventions, etc. and most of this is embedded in immediate strings inside the code.> > --mic> > > > From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Stefan AnderssonSent: Friday, October 19, 2007 6:03 AMTo: opensim-dev at lists.berlios.deSubject: Re: [Opensim-dev] Globally avaibability of config options (?)> We try to follow a layering approach, and an 'tell don't ask' approach, which would mean that the application pulls out the settings and feed them to your code, typically thru constructor initialization. Code acessing global singletons tend to get tangly and difficult to follow./Stefan> > > Date: Fri, 19 Oct 2007 08:37:38 +0200> From: Gerhard.Duennebeil at arcs.ac.at> To: opensim-dev at lists.berlios.de> Subject: [Opensim-dev] Globally avaibability of config options (?)> > Hello everybody,> > I'd like to have the ini-File-options (as well as maybe the commandline options) available in my piece of code, the meshing support for nono-trivial prim shapes.> > As a lot of its uses is completely local (debug behaviour, special settings, ...) there is no sense in distributing this through all layers between my code and the application.> > Hence it would make sense to create a global "Settings" object similar to the MainLog object.> > I can do that and create a patch for that but wanted to adress the issue before hand and get second opinions.> > Best regards> Gerhard> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20071019/ddd6a87a/attachment-0001.html>