httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: configfile_t.param
Date Thu, 28 May 1998 20:02:57 GMT

On Thu, 28 May 1998, Lou Langholtz wrote:

> Dean Gaudet wrote:
> > How do you deal with mod_perl, which uses the general configfile_t
> > interface as well?  It's param is certainly nothing you can stat to get a
> > filename.
> >
> > i.e. I really don't think we can support what you want.  You can continue
> > to hack around it as you have, but we really can't provide you a macro for
> > it.
> Well then the apache model seems broken.  A module's command_rec.func should be able
> get the (FILE *) filehandle opened for the .htaccess file with the directive(s) that
> invoked it or at least a struct stat for that file.

What FILE *?  What file?  We're talking about generalised configuration
here.  Any module can provide a sequence of directives to the core, and
they do so through the configfile_t interface.  It just so happens that
one of those mechanisms is via a FILE *.  And you were abusing the
abstraction by treating a void * as a FILE *. 

Look at pcfg_open_custom() for an example of how to generate custom
configuration files. 

> Why does mod_perl need to muck with configfile_t in it's command_rec.func'tions? Why
> would any module even be allowed to alter this data that's past on to it during the
> directives invocation phase?

We're not talking here about crud that's parsed from configurations. 
We're talking here about the configuration "files" themselves.  They're
abstracted, they don't have to be a file.  As far as modifying the
configfile_t, you're right, a module shouldn't be allowed to do that in
its command handlers.  We could put const in there to prevent that.

> If a module needs to tack on its own internal data then we
> need to add something like a linked list to which modules can tack on there data to and
> that is designed so each module can identify its tacked data node and then muck with
> it.

This is unnecessary, there are already abstractions that allow for this.

I'm sorry but I think you're going to have to find some other way to
implement what you're trying to do.


View raw message