--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.>

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.

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. The format looks as if would have been invented by a first grader. 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).


Attachment: pgpzRPpYccAEU.pgp
Description: PGP signature

Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to