httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael H. Voase" <>
Subject Re: Proposal: new config API
Date Mon, 14 Jun 1999 12:37:56 GMT
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 <some_name>

Where <some_name> 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 ?)
> 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
                                  <---- "        "
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 <blah tree="deciduous" food="tasty">
> - 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 -
> "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
 |   [ ]   |            Michael H. Voase.  Director.
~~~~~~~~~~~~~~          Castle Industries - Industrial Strength

View raw message