httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: cvs commit: httpd-2.0/server util.c config.c
Date Sun, 25 Feb 2001 02:24:31 GMT
On Sat, Feb 24, 2001 at 07:20:36PM -0600, William A. Rowe, Jr. wrote:
> > wrowe       01/02/24 16:51:32
> > 
> >   Modified:    include  http_config.h
> >                modules/aaa mod_auth.c mod_auth_digest.c
> >                modules/http mod_mime.c
> >                modules/mappers mod_imap.c
> >                server   util.c config.c
> >   Log:
> >     Clean up namespace badness with s/configfile_t/ap_configfile_t/
> This patch does something far more radical, which I believed was already
> committed (a stale util.c seems to have prevented that update, and now the
> update is in this patch.)  Sorry.
> I ment to depreciate ap_cfg_getc in a seperate patch.  It was unused within
> the Apache core, and is near impossible to make sense of in the context of
> any multibyte character encoding (jis, utc-8 etc.)
> I'm thoroughly tangled by this code, but I think I'm untangling it finally.
> I've reverted that other patch (depreciate ap_cfg_getc) and I'm probably
> for hiding more details within the internals of ap_cfg_* than actually
> removing this function - which I'm now realizing 3rd party authors may rely
> on ... and my unicode -> utc-8 transform will be just as usable, as long as
> I start a lookahead so they can have it a byte at a time.

I hate all of those functions. They're too tied to the "classic"
configuration file format. And for backwards-compat purposes, we gotta keep
them around in some form or another.

The whole config parsing/reading stuff is still a bit tangled. It is a *lot*
better than before we fixed it last year, but it also has a long ways to go.
A big component of that would be creating modules/config/ and moving all
"classic" config parsing in there. It would always be built into the server
(to appease those who don't like the variability of config files), but the
shift would help to encapsulate/modularize the code. The new classic-config
parsing module could export a header in the same way mod_dav does (that is:
it lives in modules/config and gets copied at install time; the module would
have its own linkage namespace). The core server would assume the module's
existence and always use it for parsing, but it would do so from a "third
party" position of knowing little about what is happening.

More utility functions could be shifted into util_cfgtree.c where they are
not specific to the class format.

Lastly, there would probably be a bit of change to the cmd_parms structure.
There is still a bit of stuff left over in there, which knows about the old
config files.

IOW, if you're looking for something to do, then there is a ton of highway
available :-)


Greg Stein,

View raw message