Jeremy Hylton wrote: > 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.
How about, "a lot of code/documentation was removed, and a lot of new code/documentation was added." Don't get hung up on the exact numbers, my point was, a lot of work has gone into "simplifying" the configuration process, but that the bigger picture isn't any clearer for it. > 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>. Small programs that do one thing well, written to work together, communicating via a universal interface, have the golden property of being easily replaceable. With this replaceability comes the ease of configuration. > 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. There is more than one way to ease configuration. Reducing the "amount of stuff" is one way, but sometimes, even after you've reduced till you can't reduce any further, there's still a lot of "stuff." Another way to ease configuration is to make things modular so its easier to visualize the flow of data. When the boundaries of communication are clearly defined between modules it becomes easier to understand what part each module plays, and how you can affect the overall result by changing or re-organizing the individual modules. > 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. Not I. Large applications with a master config file are to be held with suspicion. Their longevity inevitably suffers because they are difficult to adapt to new situations. > As I watched everyone working on the ZConfig project, I was > impressed with how many issues are involved in getting a decent > configuration system. Indeed. > 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. Well, when you've got some cycles to burn, give it some more thought. It may not be as obvious to you if you don't deal with it on a day to day basis like sysadmins do, but I assure you UNIX owes much of its longevity to the philosophies upon which it was built. Adaptability is a big deal. -- Jamie Heilman http://audible.transient.net/~jamie/ "We must be born with an intuition of mortality. Before we know the words for it, before we know there are words, out we come bloodied and squalling with the knowledge that for all the compasses in the world, there's only one direction, and time is its only measure." -Rosencrantz _______________________________________________ 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 )
