Andreas Jung wrote:

--On 5. März 2006 13:56:38 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote:

The right way would be to refactor ZConfig and decouple it in a
reasonable way from its dependencies.

I think this would be a major rewrite.

Possibly but I don't consider that to be a strong argument for introducing
a weaker mechanism.>

I don't think that the complexity of ZConfig is justified by the power of
hierarchical sections.

They have to deal with it now, but now it's really hard.  I think that a
approach would allow much simpler configuration support.  To extend
ZConfig now,
you have to create XML schema descriptions, and have deep knowledge of how
ZConfig works.

Why do you think it's better to have to create a monolithic schema for all
applications bits that want to use the configuration file, rather than
individual applications define how to read their own data independently?

A monolithic schema is of course a problem. I am sure it could be solved by refactoring ZConfig.

Yes.  That's why I tried to propose reimplementing ZConfig on top of the
ZCML engine a few weeks ago.  If that was the only goal, then I think
this would be the way to go.

There could still be frameworks to make handling configuration data

I agree but I really dislike the idea of flattening a hierarchical structure into a INI-like format. Having /x/y/z as section names looks both funny and somewhat unprofessional.

Obvoiously, this is a matter of taste.  Many people are put off by even
the hint of XML in ZConfig.

> The format looks as if would have been
invented by a first grader.

It probably was. ;)

> There is no question that ZConfig has the
problems you described.  But I consider such a flat representation as
poor and a step back
instead of a step forward (independent of the effort needed to simply and refactor ZConfig).

I agree, however, I think that there are other benefits of a move to
ConfigParser that far outweigh this disadvantage.


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

Reply via email to