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:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
