Re: [Zope] Re: [Zope-dev] Proposed installation changes for review
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
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
On Tue, 2003-03-11 at 17:48, Jamie Heilman wrote:
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.
Given the circumstance, what would you propose to do? - C
Chris McDonough wrote:
On Tue, 2003-03-11 at 17:48, Jamie Heilman wrote:
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.
Given the circumstance, what would you propose to do?
Merge and move on, I'm not asking anyone to throw out their work, just to give thought to what I've said. -- 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
On Tuesday 11 March 2003 10:48 pm, Jamie Heilman wrote:
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.
Im not sure the "big config file" approach is necessarily less adaptable than the "big /etc directory" approach. It is the details that make the difference - both approaches can be done well.
Another way to ease configuration is to make things modular so its easier to visualize the flow of data.
There is no amount of reconfiguration that can improve this in Zope2. Zope3 promises to fix this, but with modular python components rather than modular unix components. I would be interested in your thoughts on whether this makes a difference. -- Toby Dickenson http://www.geminidataloggers.com/people/tdickenson
Toby Dickenson wrote:
There is no amount of reconfiguration that can improve this in Zope2. Zope3 promises to fix this, but with modular python components rather than modular unix components. I would be interested in your thoughts on whether this makes a difference.
I don't think modular component libraries are a replacement for modular programs, or vice versa. They both have their place, they both can be good or bad depending on the implementation. (How's that for a wishy-washy say-nothing statement. <g>) I simply haven't looked seriously at Zope3 yet, because my needs and Zope3's timeline don't coincide. So unfortunately any opinons I could offer on Zope3's direction would be wholely uninformed. -- 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
participants (4)
-
Chris McDonough -
Jamie Heilman -
Jeremy Hylton -
Toby Dickenson