httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <do...@covalent.net>
Subject Re: <Perl> vs. external config
Date Thu, 27 Apr 2000 01:08:01 GMT
> If you're worried about the case where only part of your configuration
> is generated by Perl, then the perl script can process the existing
> configuration easily, iff the httpd configuration syntax is stupidly
> easy to parse.

it doesn't matter to me how "easy" it is to parse, Apache already has a
config parser, i want to reuse that code.  again, how do i know what the
parse rules are?  TAKE1, TAKE2, TAKE3, ITERATE, etc., are all defined in
the command_rec, is the external parser expected to duplicate that info
for every module's command_rec ?

another area an external parser cannot deal with is generating config at
request time, based on info in the request_rec, which can be done with
<Perl> sections in .htaccess files.

> I don't see a problem with having lots of files around. It's not like
> config files are multi-megabyte or anything.

i'm not concerned with size, i'm concerned with the clutter of multiple
generated files.
 
> With qmail-style configuration, we might be able to use symlinks. Or,
> the external parser can easily do this task as well. In fact, the
> sandboxing setup I'm working on at Collab uses an external parser
> (Perl-based of course).

that's your sandboxing setup, other people already have their own based on
a simple mechanism that's been around for 3 years.  i don't like the idea
of taking it away.

> I guess this one's kind of nice. But, I'd say that if you can't trust
> the filesystem permissions on your drive, I think you have bigger
> problems.

maybe, but that's your opinion (which i share, but), i'd like to leave the
decision to the users, not us.

> I don't quite understand this one. The current config isn't otherwise
> available to the Perl code right now? Well, this setup makes that
> easier. :)

what it means is that any variables defined in a <Perl> section are
available to Perl code running in that process.  this allows Apache and
application code to share configuration without have to parse it twice
with two different parsers.
 
> If the accessibility of the rest of the Apache config is dead simple
> (and I think that's mandatory for the external config parser idea to
> work), then I don't think it's a burden for a webmaster to write his
> own Perl code to fill in the missing details of an Apache config if he
> was already planning to use embedded Perl in the config file anyway.

again, how does the external parser know the parse rules defined in the
command_rec's ?  and again, i don't care how "simple" the config is to
parse, there's already a parser inside Apache, i want to reuse it.
along with reusing other pieces of the already defined/implemented api i
pointed out.

i don't understand what the problem is with leaving this option open.  if
you want to use an external parser/generator, fine.  all apache has to do
to maintain the other option is to allow a <Container> to contain an
arbitrary chunk of text that is handled by a third-party module.  where is
the harm in that?


Mime
View raw message