[PEAK] Unifying configuration

[Phillip J. Eby]

One of the issues that affects development of things like the performance 
timer service (and the coming ILoggingService) is the ability to configure 
multiple handlers, listeners, and the like.

These types of configuration seem to want to have the ability for files to 
add items to a list (such as timer-listeners, or log 
handlers/formatters/filters/etc).

Currently we have two distinct configuration formats, .ini and 
ZConfig.  They are about as opposite as you can currently get.  ZConfig is 
schema driven, imperative, immediate, nested, and allow for multiple 
objects or values to satisfy a configuration request.  PEAK .ini files, on 
the other hand, are largely free-form, declarative, lazy, flat, and provide 
only one value per key.

The issue of listeners and certain other types of configuration, is that 
one needs the multi-object and nested aspects of ZConfig, while retaining 
the lazy and declarative aspects of .ini files.

Ty and I have been batting around a few ideas for what to do about this 
that mainly involve some incremental adjustments to the .ini 
format.  However, I've had another idea just this morning that is either 
really beautiful or thoroughly hideous, I'm not sure which.

Suppose we made it possible to use ZConfig *inside* an .ini 
file.  Something like:

[Configuration for timer:foo.bar]

<FileListener>
...
</FileListener>

<SpreadListener>
...
</SpreadListener>


That is, what if we made it possible for an .ini section handler to parse a 
different format for that section?  As long as that format doesn't have any 
lines starting with '[' (and ZConfig files don't), it would be 
*technically* quite feasible.  The idea is that the section would install a 
configuration rule that, when invoked, would actually do the parsing of the 
ZConfig part in order to create the object(s) needed for that configuration 
rule.

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?

A slightly less ambitious approach would be to define the ZConfig data 
inside of a rule, like this:

[peak.foo.bar]
baz = ParseZConfig("""
     %import my.package
     <SomethingFromMyPackage>
     SomeSetting spammity spam
     </SomethingFromMyPackage>
     """)

Of course, you couldn't use triple quotes without escaping them, and there 
might need to be some kind of de-indenting mechanism.  This approach is 
awkward, discouraging its use even for things that it's appropriate for.

So one more possible approach:

[Special section of some kind for something blah...]

foo.bar =
     %import my.package
     <SomethingFromMyPackage>
     SomeSetting spammity spam
     </SomethingFromMyPackage>

That is, in certain special sections, you can use ZConfig nested within a 
setting, without needing any quotes.  (Naturally, such sections would be 
using *only* ZConfig for settings; pure Python would not be an option in 
such sections.)

These latter two syntaxes have the advantage of fitting a bit more cleanly 
into the overall .ini look-and-feel of the file.

Thoughts, anyone?