Return-Path: Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 37103 invoked by uid 500); 8 Jan 2002 21:18:51 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 37087 invoked from network); 8 Jan 2002 21:18:50 -0000 Sender: root@main.aquanet.co.il Message-ID: <3C3B5FF2.798273A6@netmask.it> Date: Tue, 08 Jan 2002 23:09:06 +0200 From: Eli Marmor Organization: Netmask (El-Mar) Internet Technologies X-Mailer: Mozilla 4.08 [Hebrew Support by elmar.co.il (X11; I; Linux 2.0.36 i586) MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: API for runtime httpd config ? References: <012f01c1982e$aa3f5780$7500a8c0@goliath> <001d01c1984f$b96ea8c0$0500a8c0@hamm.com> Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ilker ARABACI wrote: > Is there any API used or on progress to get httpd global and configuration > values on runtime, > (not an httpd.conf file parser), something and more detailed like info > module does, > And also it would be more helpful to manuplate what will httpd act as > without restarting nor reloading, > to keep the active (unrelated to changes) sessions and connections up. Your questions raised a serious drawback of Apache: on-the-fly administration/configuration. In my humble opinion, it's even the main drawback of Apache (and the only thing that stands between Apache and perfection). Historically, any module parses its directives. There are some public functions, but they are too basic, and each module decides what is valid and what is not, how to translate each string, and even where to store it. Some directives even use a "raw" parsing - i.e. no rules regarding how many flags the directive should have. Modules may even ignore directives. Asking Apache to re-read its configuration is problematic too; Even the primitive way, of "killing" it, is impossible, because a non-root user can't kill a root user, even if it is its parent. Also, there is no mechanism for transferring messages from the children to the parent initiated by the children, but only vice versa (e.g. scoreboard). There are some "creative" alternatives, like exiting with codes that the parent will "understand" as requests to do specific things (like stop/ restart/graceful), but this method is too tricky, doesn't work in 100% of the cases and the platforms, limited (you can't pass more details), and has a lot of other problems. These problems makes the mission of developing a GUI for Apache almost impossible, and the results - although should be admired considering the tight constraints - are very disappointing. Some solutions for both problems were discussed in the past. A *MAJOR* change in the format of httpd.conf and its handling could help. For example, migrating to XML, and replacing the conf structures by structures with offsets to the member in another structure where the module stores its attributes, plus functions for validation/conversion /reverse-conversion for each "type", could resolve almost everything. It helped X (although the syntax was a little different - not XML), and there is no reason why Apache should differ. Of course, adding a pre-processor which will convert XML syntax to the current syntax, doesn't solve anything... "Unfortunately", Apache is the most popular web server, and millions sites are already powered by it. It means that millions configuration files will not be compatible with the new syntax. In addition, there are hundreds of modules, and all of them will not be compatible with the new syntax and C structures, unless ported to them. This is why the "revolution" will never happen, so your questions will remain unanswerred forever. Note: We are trying to add functions to meet your second need - apr_stop(), apr_restart(), apr_graceful(). When one of these functions is called by the parent, it will stop/restart/graceful itself. When it is called by a child, it will inform the parent in a special "pipe" that will be listened by the parent. Once the parent receives anything in this pipe, it will decode it, and call anything needed. If it works perfectly with all the MPMs, we will probably contribute it. -- Eli Marmor marmor@netmask.it CTO, Founder Netmask (El-Mar) Internet Technologies Ltd. __________________________________________________________ Tel.: +972-9-766-1020 8 Yad-Harutzim St. Fax.: +972-9-766-1314 P.O.B. 7004 Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel