> 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

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.


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to