httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Gambarin <>
Subject apache handlers (1)
Date Mon, 04 Aug 1997 17:58:13 GMT

	In its current state, modules are required to provide a module 
structure, which lists any handlers in the current module that should be
invoked by the server during various phases of the request processing, i.e
access_checker, logger, etc.  This approach (using a structure) provides a
very inflexible solution, where an addition of an extra stage to request
processing requires change to all modules, subsequently causing lost of
backward compatibility of the old modules.  This idea popped up after 2 
huge diffs which added child_init, child_die stages to modules, and I am
not even mentioning any external modules.
	The new idea is to allow modules to register the stages of the 
execution they would be interested in, instead of module specifying it in
the module structure.  This would provide the following advantages:
	- module is only called when it is interested in a stage, i.e
	module has registered a handler.
	- BACKWARD COMPATIBLE: addition of the new stages to execution
does NOT break any existing modules, as they do not care about new stages
and only new modules would need to register them, thus limiting the change
only to the core.
	- allow for dynamic [un]registration of the module handlers during 
runtime.  This can be useful for dynamically [un]loaded modules, as well
as subrequest mechanism, where i need to find a type of a file, why do i
have to invoke method to check_user_id, so this should provide a boost
(well, ok a bump) in performance.

	What i did ... I took existing 1.2.0 code (prior child_[init|die])
removed all static handler registration and stuff them into init() call 
for every module - see example core module.  I then provided a static 
variable that contains all handlers (g_hndlers g)  Since I had used a
linked list, i also changed the order of the modules , although i do not
know if that was necessary.  Notice that current design does not 
provide for dynamic [un]registration, as i want to figure out what people
think about it and maybe someone who is more familiar with a core and 
request processing can implement it in a more optimized form, i.e. array
of handlers instead of linked list, dynamic registration, modified sub_req
mechanism ?  Diffs attached below should serve as a starting ground.  

	On a separate note, 2 requests - 
	- how about adding internal version number field to each module,
so that external and distributed modules can track any changes,
incremented every time something is changed - would be a good reference
point.. (example: i had foo broken in module bar, version 019209)
	- how about adding a debug target for the Makefile, since now I 
have to manually go to Makefile, remove any $OPTIM flags and add -g to 
CFLAGS, which is ok, but i'd rather have this automated in some way...


View raw message