[Zope3-dev] Re: RFC: Use ConfigParser for High-Level Configuration

[Jim Fulton]

Philipp von Weitershausen wrote:
> Jim Fulton wrote:
> 
>>  http://dev.zope.org/Zope3/UseConfigParserForHighLevelConfiguration
>>
>>Is a proposal for using ConfigParser, rather than ZConfig for high-level
>>configuration.
> 
> 
> +0
> 
> I see the advantages of using ConfigParser, especially being able to
> configure more than one instance in an .ini file as well as the
> interoperability with other software that uses them (e.g. paste.deploy).

I think this is very important.   There's also the fact that the ini
format is, for better or worse, more familiar than the apache format.


>  At least the first point, however, doesn't require us to ditch ZConfig.
> As you mention, a possible solution is to fix ZConfig's shortcomings
> with respect to the centralized schema definition and the push-vs.-pull
> issue.

Given that one can write a translator from ZConfig to ConfigParser, this
is certainly possible.

> Looking at your examples (especially the long one), I find the ZConfig
> version much easier to read.

I think this is a matter of taste.  All config formats suck or rock on
some level.

 > Perhaps the .ini format could be compressed
> more. It seems like one has to create a new section for every little
> detail (but then again, you have to create a "tag" for every little in
> detail in the ZConfig version too).
> 
> How about an .ini file like this:
> 
>     [DEFAULT]
>     INSTANCE = /home/jim/sample_instance
>     CONFDIR = %(INSTANCE)s/etc
>     DATADIR = %(INSTANCE)s/var
>     LOGDIR = %(INSTANCE)s/log
> 
>     [zope]
>     site-definition = %(INSTANCE)s/etc/site.zcml
>     interrupt-check-interval = 200
>     devmode = off
> 
>     server = zope/server
>     zodb = zope/zodb
>     accesslog = zope/accesslog
>     eventlog = zope/eventlog
> 
>     [zope/server]
>     server0/name = http0
>     server0/type = HTTP
>     server0/address = 8080
> 
>     server1/name = http1
>     server1/type = HTTP
>     server1/address = 8081
> 
>     server2/type = PostmortemDebuggingHTTP
>     server/2address = 8082
> 
>     [zope/zodb]
>     zodb0/name = main
>     zodb0/type = filestorage
>     zodb0/path = %(DATADIR)s/Data.fs
> 
>     zodb1/name = a
>     zodb1/type = filestorage
>     zodb1/path = %(DATADIR)s/A.fs
> 
>     # example added by philiKON
>     zodb2/name = b
>     zodb2/type = directorystorage
>     zodb2/path = %(DATADIR)s/dirstorage
>     zodb2/readonly = off
> 
>     [zope/accesslog]
>     log0/path = %(LOGDIR)s/access.log
>     log1/path = STDOUT
> 
>     [zope/eventlog]
>     log0/path = %(LOGDIR)s/z3.log
>     log0/formatter = zope.exceptions.log.Formatter
>     log1/path = STDOUT
>     log1/formatter = zope.exceptions.log.Formatter
> 
> Basically, an instance section (e.g. [zope]) would only refer to four
> other sections (server, zodb, accesslog, eventlog) which would not refer
> to more subsections. Instead they use more complex keys.

I don't find this any nicer looking and I think the resulting data structures
are too complicated.  The appeal of what I proposed is that software that
reads a ZODB section ot a logfile section doesn't have to filter the options
or know that the section is shared with other handlers.



> Of course, the
> resulting data structures would no longer be compatible with ZConfig.
> 3rd party code like DirStorage (example added above) would have to be
> adjusted. This could create a lot of BBB pain.

As I mentioned in the proposal, we will have to convert or rewrite
existing configuration support, which is a pain.  I think that
the existing pain that ZConfig causes far outweighs this.


> Anyways, just some ideas.

Thanks!

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org