Chris McDonough wrote:
> Before dismissing it out of hand, I'd encourage you to try it out.
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
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
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.
Jamie Heilman http://audible.transient.net/~jamie/
"Paranoia is a disease unto itself, and may I add, the person standing
next to you may not be who they appear to be, so take precaution."
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -