[Zope] Re: [Zope-dev] Proposed installation changes for review
Jeremy Hylton
jeremy@zope.com
11 Mar 2003 13:45:34 -0500
> I'm not dismissing it, and I think you need to go back and read what I
> wrote again very very carefully without reading anything into it. I'm
> not trying to imply that using environment variables to configure the
> current codebase will reduce the code footprint. Even if it did,
> because of the distributed nature of the technique, its damnedly hard
> to maintain in a project as large as Zope. Also, I didn't say ZConfig
> was 374k of code, I said it was 374k of *work*. I chose that word
> very carefully, and obviously thats going to err on the side of
> conservatism as certainly the work was not isolated to that single
> directory tree.
I don't know what work means in this context, but think the ZConfig
project is thorough. In my checkout there are 180k of document, 180k of
unit tests, and 136k of code. A measure of work that suggests that
something with 0k of documentation and tests and 136k of code would be
better makes no sense to me.
> The point I'm trying to make is that Zope has learned nothing from the
> UNIX philosophy. Yes, you can extend the config schema. You can grow
I don't see where the UNIX philosophy has anything useful to say about
configuration, but maybe I'm just a closet unix hater <0.5 wink>.
> new, better config files, of extraordinary magnitude. The
> all-powerful server will grow from being all-powerful to being
> all-powerful + n. It will be able to read mail. Its heralds shall
> sit upon mountain high throwns hewn of the finest O'Reilly and New
> Riders scripture. But lo, still you won't be able to do something as
> mundane as limit the memory the FTP server is able to consume without
> affecting the HTTP server.
> Fracture the server infrastructure into small, seperate processes.
> The configuration of the individual pieces becomes trivial. The
> understanding of the overall data flow improves. When there's nothing
> left to remove from code, you've won. Some of the breaks have already
> been made, like the separation of the storage from its front-end.
> Thats good, we need more action along those lines.
I don't see that configuration gets any easier if you have multiple
processes. Even if Zope had N processes, there would still be the same
amount of stuff to configure. You'd probably still want a single master
config file for the whole thing, and a tool to check the configuration
is valid separate from the process that uses the file to configure
itself.
As I watched everyone working on the ZConfig project, I was impressed
with how many issues are involved in getting a decent configuration
system. I don't think that break the server into multiple pieces would
make it easier to configure, and I don't see what requirements could
have been eliminated to make the project take less work.
Jeremy