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

[Stuart Bishop]

Jim Fulton wrote:

> Have you written a ZConfig schema?  Have you tried to read the
> documentation on writing one? Have you writtem an application
> that uses ZConfig? If you had, I think you'd know what I was
> talking about.

I have. Our chunk of our schema.xml is over 600 lines including comments and
whitespace and defines 22 sections.

We needed a configuration mechanism for Launchpad and related tools. I
decided to go with ZConfig to integrate our configuration with the rest of
the Z3 configuration. This was with Zope 3.0 and integrating our config with
the Z3 config was quite problematic.

We gained a little doing it this way. Having the Z3 configuration with our
own configuration information made is easy to maintain the multiple configs
we need to maintain (several production configs and developer workstation
configs, maintained in the RCS alongside the code). In theory, we could
generate documented configuration templates but we haven't done that -- we
just maintain the commends in 'default' configuration.

We lost a fair bit of flexibility doing it this way. Field validation needs
to be done the ZConfig way. There are issues with non-required fields in
non-required sections giving us grief. There seem to be namespace issues,
despite being hierarchical (eg. we have <librarian><librarian_server>
instead of just <librarian><server>, it seems because <server> is already
used by Z3 so we can't call our section that). These issues might be ZConfig
in Z3.0 issues, or problems with how we are using it. If the issues we are
having are our fault, I would also call that a problem with ZConfig as the
documentation is not detailed enough to match ZConfigs complexity. Pulling
in configuration information should be light weight, but I find ZConfig puts
too much burden on developers for little gain. Despite being very complex,
it seems to lack features that we need or the features don't work the way we
need them too (eg. we really need to say 'this config file is identical to
that one, except these fields are changed. Extending ZConfig to do this did
not seem fun.).

An alternative would have been a .ini or xml format similar to what you have
already described. I elected to proceed with ZConfig to see how we went and
to integrate our config with Zope3's. In hindsight, I think we would have
had a simpler, more flexible and more easily extensible system if we had
gone with .ini or xml instead.

Migration for us shouldn't be a problem, we access to our configuration is
via a simple API so we can replace the guts. I expect to reimplement our
config machinery when I get a chance to work on low priority tasks (we have
issues with what we have, but it works).

So +1 I guess. Although I personally would prefer using XML, as I think it
will be more readable for complex configurations as it is better able to
represent heirarchies and provide more flexibility to developers.

-- 
Stuart Bishop <stuart at stuartbishop.net>
http://www.stuartbishop.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: OpenPGP digital signature
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20060313/1473ea03/signature.bin