Philipp von Weitershausen wrote:
Jim Fulton wrote:

Is a proposal for using ConfigParser, rather than ZConfig for high-level


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

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:

    INSTANCE = /home/jim/sample_instance
    CONFDIR = %(INSTANCE)s/etc
    DATADIR = %(INSTANCE)s/var
    LOGDIR = %(INSTANCE)s/log

    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

    server0/name = http0
    server0/type = HTTP
    server0/address = 8080

    server1/name = http1
    server1/type = HTTP
    server1/address = 8081

    server2/type = PostmortemDebuggingHTTP
    server/2address = 8082

    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

    log0/path = %(LOGDIR)s/access.log
    log1/path = STDOUT

    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.



Jim Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714  
Zope Corporation
Zope3-dev mailing list

Reply via email to