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

[Stuart Bishop]

Chris Withers wrote:
> Stuart Bishop wrote:
>> the Z3 configuration. This was with Zope 3.0 and integrating our
>> config with
>> the Z3 config was quite problematic.
> 
> What were the problematic bits?

# Disgusting hack to use our extended config file schema rather than the
# Z3 one. TODO: Add command line options or other to Z3 to enable overriding
# this -- StuartBishop 20050406
from zdaemon.zdoptions import ZDOptions
ZDOptions.schemafile = os.path.abspath(os.path.join(
        os.path.dirname(__file__), 'lib', 'canonical',
        'config', 'schema.xml'))

Also, there is only one schema.xml so multiple components can't each insert
their own blob of configuration information into the global schema.

>> We lost a fair bit of flexibility doing it this way. Field validation
>> needs
>> to be done the ZConfig way.
> 
> How would you prefer to do it?

Validation of the entire config file, and if there are one or more errors
output a readable report at the end with error messages returned by the
validators. The current mechanism just spits out exceptions, which is really
bad for configuration files aimed at end users.

>> There are issues with non-required fields in
>> non-required sections giving us grief. 
> 
> Can you describe these a little?

If I have a non-required section foo, containing a non-required key bar, if
I try and access config.foo.bar I get an AttributeError. I should get the
default value for bar. This causes noise in our config files and a
maintenance burden where we have to include non-required sections just so
the default values of keys will be accessible.

>> 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.
> 
> My main gripe with the .ini format is the lack of hierarchy, but then I
> worry that with XML we'll suffer from an overly complex schema...

Why would you want a schema for the XML?
  - The config file could just be arbitrary well formed XML.
  - validation handlers would be registered for a particular XML namespace
  - Config file is loaded into a set of data structures, one for
    each XML namespace
  - warnings are emitted if there are XML namespaces loaded that don't have
    a validator.
  - validators are called, giving them a chance validate and
    convert values to native types. They are allowed to raise an error if
    they find stuff they don't know about lurking in their namespace.
  - the resulting datastructures are available via a thread global

For sane config data, I don't think the sucky bits of XML need to be worried
about. It is pretty unlikely that you need to include <> or & symbols or
wierd Unicode hieroglyphs in your configuration data (but if you do, at
least you already know how to insert it because we all know enough XML now
to do this).

Of course, .ini would be able to emit more meaningfull error messages:
foo/bar/1 in section [whatever] is required, but not found
blah/whatever in section [whatever] is not a valid url
section [baz] is required but does not exist.

-- 
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/20060320/37fb8737/signature.bin