httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <>
Subject Re: Configuration modules...
Date Fri, 14 Apr 2000 00:31:42 GMT
On Thu, 13 Apr 2000, Greg Stein wrote:

> Consider the case where the data comes from LDAP.

LDAP is just a fancy name for filesystem with extra indexes, especially
considering that you're configuring a url-space, which looks pretty much
like a file system.

> How do you synchronize
> changes in LDAP with the XML config file?

if you want to store configuration in LDAP then store it in the XML
configuration language.

> There are certain types of configuration sources that simply do not map
> well to "here is a config file."

you've yet to demonstrate one.

> I think what you should argue for is the capability to read config data
> from a pipe. The other end of the pipe can grab the data from the source,
> format it as XML, and shove it down the pipe.

i've argued for that pretty much every time this debate comes up.

> IMO, we still want the modularization around the config stuff so that we
> can read it from a file or read it from a pipe. Of course, that's just
> reading from an fd, but there are more benefits to modularization.

the topic has come up before.  what would be best is to fix apache's
filesystem-centric view of the world.

ap_bopen("ldap://blah/blat") should work just as well as ap_bopen("file")
does (as should ap_bopen("http://config-master/blahblahblah")).

abstract the few minor properties that we use of files:

- dir structure (i.e. url path)
- filename
- last-modified

the few properties that you actually need to serve up a response in HTTP.  
we currently do a stat() for some of these properties.

and then let people write modules which mount backends into the url-space;
or overlay backends; etc.

then fix the .htaccess parsing code to cache .htaccess files and use a
GET-If-Modified-Since to update the cache.

then realise that that type of .htaccess caching is really the same as
HTTP caching... and unify the caches.

doesn't that sound far better?  this is what's been suggested before...
the caching stuff is an optimisation that doesn't need to come


View raw message