Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 13456 invoked by uid 6000); 14 Jun 1999 12:32:06 -0000 Received: (qmail 13442 invoked from network); 14 Jun 1999 12:32:03 -0000 Received: from ecpport2.ecopost.com.au (HELO ecpport2.midcoast.com.au) (203.28.64.15) by taz.hyperreal.org with SMTP; 14 Jun 1999 12:32:03 -0000 Received: from midcoast.com.au (kmidc65-10.ecopost.com.au [203.28.65.10]) by ecpport2.midcoast.com.au (8.9.1/8.8.5) with ESMTP id WAA25996 for ; Mon, 14 Jun 1999 22:31:54 +1000 Message-ID: <3764F7A4.1786EEF2@midcoast.com.au> Date: Mon, 14 Jun 1999 12:37:56 +0000 From: "Michael H. Voase" X-Mailer: Mozilla 4.06 [en] (X11; I; Linux 2.0.36 i586) MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: Proposal: new config API References: <19990614012148.D6767@io.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org OK I gotta put in me 2c worth here ....;) Just as a quick note , I am currently in the throws of putting some of whats discussed here into Apache pthreads . Got nothing but headaches so far but me road map is slowly clarifying ... Manoj Kasichainula wrote: > > > This'll be quite useful for mostly static configs. It won't be useful > for those sites using lots of dynamic DAV configuration. We could > allow partitioning the config directive space, and have separate flags > for each partition. Hmmm... > Ok hows this for a partion serving suggestion . No new module required just some small additions to http_core . I am looking at the concept of a 'ServerBuild' at the moment . The concept being based on a dynamic shared object build using the ServerBuild as a container . Its going to look something like ServerBuild Where refers to an additional config file that is loaded by a server child ( Im talking pthread stuff here , not 1.3.7 . However it is not a far stretch of the imagination to include a ServerBuild in 1.3.x then specify the number of processes that will use that build - might be usefull for people running mod_php and mod_perl in the same server ;) .Before anyone yells at me about 'we have only just narrowed down the config to one file' just spare a thought for all the admins running large vhost sites . Could be a blessing to break up monstorous http.conf files to , lets say http.conf + company_X.conf , company_Y.conf company_Z.conf , general_users.conf , priv_users.conf etc on a user defined basis ...no ?) > Maybe the config module can also return integers for each directive > registered, presumably hash indices. Then, every config lookup > wouldn't require a strncmp. > Why not just use the existing config method . Apache just does a recursive getline on the config file . Change the routine so it can do a getline on a socket pipe or whatever . > The calls I've thought of or heard from here so far (with > error-checking ignored for now): > > int ap_init_config_module(pool/context) > > void ap_register_config_directive(char *directive_name, > ap_directive_arg_desc_t types_of_arguments, ...); > > This could include help text, and a partition identifier too. > The unregister would be a pool cleanup > > void ap_get_config_value(char *directive_name, > ap_config_value_t **config_value); > > void ap_get_config_value_from_hash(int directive_hash, > ap_config_value_t **config_value); > > ap_set_config_value(char *directive_name, > ap_config_value_t *config_value) > > ap_set_config_value_of_hash(char *directive_name, > ap_config_value_t *config_value) > > ap_check_changed(int partition_id); > Howabout just ap_handle_command ? I groks through all the modules . Just use some front end to edit the new config you want , open a socket to your http server and dump the config ? Well not without some extra krufting ;) However one of the items I delving into with this serverbuild stuff is to put in a slective server restart . Me principle operates like this . During wait_or_timeout ( called from server_main_loop ) , the monitor does an non-blocking waitpid() . If no children have died then it does a select() on a NULL file descriptor . Substitue an admin socket or some such file descripto in there and you can have the monitor doing interactive reconfiguration for you as well as its other duties ;) Me concept for pthreads is like this admin pipes from threads <----thread_main_loop <---- " " admin_socket <--- server_main_loop<---- " " <---- " " ( hehe - yes I am playing around deep in the guts of pthreads ;) With each monitor selecting on its admin pipe during wait_or_timeout . That way when a new command or config arrives , the monitor can act on the command when it has a spare moment ... ( of course then theres the admin pipe API to contend with ... but I'll leave that to your imagination 8) For 1.3.x apache the scenario could look something like :- admin socket <--- server_main_loop Since there is only one monitor ... > So, are these things worth the effort and complexity: Only if one applies the KISS rule liberally and reuses as much of the existing code as possible ;) > > - partitions with independant change notification > - hashed config directives > - Supporting XML node attributes (I forget the actual term that the > XML geeks use) as in > - Supporting limiting what scopes directives can be used in. > Limit scoping using a container that is loaded only in the child process ( like ServerBuild ..;) Anyways just some food for thought ... > -- > Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/ > "Some people have entirely too much free time on their hands." > - Gene Spafford (spaf) Cheers Mik Voase. -- ---------------------------------------------------------------------------- /~\ /~\ CASTLE INDUSTRIES PTY. LTD. | |_____| | Incorporated 1969. in N.S.W., Australia | | Phone +612 6567 1227 Fax +612 6567 1449 | /~\ | Web http://www.midcoast.com.au/~mvoase | [ ] | Michael H. Voase. Director. ~~~~~~~~~~~~~~ Castle Industries - Industrial Strength Solutions. ----------------------------------------------------------------------------