> 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 _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
