[PEAK] Unifying configuration

[alexander smishlajev]

Phillip J. Eby wrote, at 19.12.2003 21:12:

>>> What I'm wondering about is whether this would be too brain-boggling 
>>> of a syntax.  So far, .ini files have a comforting regularity to 
>>> their format.  So, if you wander through and see something like this 
>>> in the middle, what would you think?
>>
>> with all the complexity of current peak.ini file contents, i do not 
>> think that these syntax variations will be a big problem.
> 
> But currently, all the contents consist of [sections] with 
> 'setting=value' lines.

yes, but value (and maybe setting) semantics are *very* different in 
different sections.  in addition, value may include python code with 
unlimited complexity.  as far as i understand the matters.

because of this, to read and understand an .ini file human needs much 
more intelligence than just finding equality signs.  IMHO.

> Different section handlers are already allowed, so long as they follow 
> the 'setting=value' pattern.  The 'value' need not be a Python 
> expression, even though most existing section handlers are.

we didn't know that.  thanks.

> In fact, I'm about to add a new section handler, "[Import on Demand]", 
> which will allow you to define shortcut names so you don't need to use 
> importString or importObject in .ini files if you don't want to.

> With this addition, a lot of the need for using ZConfig syntax in .inis 
> will go away, since you'll be able to very cleanly create even complex 
> objects in an expression.

but this will not eliminate the issue that caused us to switch from .ini 
to ZConfig: to read a component settings from .ini file we must know 
that our application contains that component.  with ZConfig, the list of 
included components is naturally created from component sections.

there are additional bonuses of including separate ZConfig sections in 
.ini file, compared to ".ini-only" or "ZConfig-only" approaches as well 
as a mix discussed in "runIni => ZConfig revisited" thread started at 
http://www.eby-sarna.com/pipermail/peak/2003-November/000872.html

pure ZConfig is a one-in-a-whole thing.  if there is an error (either 
syntax error, or environment error, like missing directory, preventing 
an instantiation of at least one component) the application does not 
start at all, even if 90% of it are ok.  if we need to change a setting 
for one component, we have to restart the whole application.

by keeping the text of ZConfig inclusions and parsing them at the time 
they are accessed we could isolate single component problems without 
disturbing other components.

if ZConfig inclusions are kept as a text and parsed upon access, we 
could also implement a dynamic reconfiguration of some components by 
utilizing ZConfig '%include' feature: included file is read at the time 
of ZConfig parse.

best wishes,
alex.