Hi Robert! > The syntax and help can actually be done by brute force if need be, although > I'd welcome any changes to make the config files easier to parse. The bigger > issue is how to affect configuration changes at run-time.
I have done it by brute force. I can assure you it is prone to errors and definitely not funny... > Most configuration tools are based on the idea of editing the configuration > files, and then restarting the server. What is really needed is a > coordinated way to send changes into a running server with the option of > saving these to the configuration files. Obviously not every configuration > option could (or should) be dynamically configurable, but avoiding a restart > to make minor changes seems critical to sites that need high-availability. > > This can be accomplished several ways, but all of which require a > cooperative effort with the guys developing the server. What springs to mind > are the following: > > * shared memory between gui/apache to change configuration values on > the fly. Apache needs to be aware that values can get yanked out from under > it and saves values during critical sections. > * A trigger to re-read the configuration files without shutting down > * An API to send config changes to > * ?? Quoting from Marc Slemko in a response to a similar proposal: " No. You really have to change the config files and restart (USR1 or HUP). Not only is this required for consistency (if you think you can both change the config files and be 100% sure that the changed config files will do exactly the same thing that your config changes do, you are almost certainly wrong), but if you change the config in one child then it will only apply to that one child process. Even if each child changed its own, then it would still end up eating more memory. So you are left with having to change them in the parent and respawn child, which is what a restart does anyway." You can get the original discussion at http://www.dejanews.com/getdoc.xp?AN=406808068 Regards Daniel [EMAIL PROTECTED]
