httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Gambarin <stanl...@cs.bu.edu>
Subject Re: config files stuff
Date Thu, 17 Jul 1997 23:01:44 GMT
	A couple of objections to ditching existing directives...
a. Existing system tries to be a drop-in replacement for NCSA (at least
that's what documentation says), and that includes config files.  So, 
as far as I understand, 1.3. will retain current config but 2.0 might change 
dramatically (read incompatible), so solution is to retain Access and 
Resource for 1.3, but get rid of them for 2.0
b. You are proposing #include mechanism, where the file is included as 
it is defined.  This is not a current behavior, as Resource and Access
are processed after all of the main config is done.  Second, this would
in fact introduce recursion problems, where file "a", containing
the directive IncludeConfig "a" would result in infinite loop., so it
would not be KISS.  
c. My personal opinion on the subject is (i don't know if the following 
is possible or what):
	- parse each file, where info in each file would result in the 
so-called node in the config tree.
	- when USR1 is recieved, server checks which one of the config
files has been modified (if any), locates that node and then replaces
that node, instead of reparsing all config files.
	- anything that needs access to config directives would traverse
the config tree to find info.
	Note that I have no idea as to how possibly implement the above,
but would love to hear some suggestions.  Also, some sort of the config
compiler would be great to avoid parsing strings (which is so slooow)
every time some directive is needed.
						Stanley.

Mime
View raw message