httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [PATCH] Disabling logging based on envariable
Date Mon, 18 Aug 1997 17:31:36 GMT
Maybe I was confusing your <If> with Ben's way more general syntax.  If
your proposal back then was only to test against environment variables
then I'm sorry!  I was confused. 

It would be possible to tie something into subprocess_env modifications... 
but I wouldn't want it to happen on each modification.  I'd rather it
happen at "sequence points".  We can make sequence points wherever we want
to ... but the finest granularity I'd suggest is after each module method
call.  If you do it while a module method is running you run the risk of
the subprocess_env being in the middle some partially completed
computation (i.e. add foo, remove bar).

This could be made to be not so expensive ... we'd need to know if
subprocess_env was modified.  Your suggestion can work to find out exactly
what subset of <If>s need to be re-run, but might be hard to implement...
dunno.

Dean

On Mon, 18 Aug 1997, Paul Sutton wrote:

> On Sun, 17 Aug 1997, Dean Gaudet wrote:
> > On Sun, 17 Aug 1997, Paul Sutton wrote:
> > >   <If !is_bad_robot>
> > >    CustomLog ...
> > >   </If>
> > 
> > Adding another scope for this isn't expensive... I was going to suggest it
> > too, but I couldn't decide when in the ordering to do this merge.
> 
> Erm, last time I suggested a generic <If> container, you wrote:
> 
> |I am really concerned that this totally generic language is going to
> |become one of our worst mistakes ever.  Reasons:
> |
> |- performance.  This can't be made to go fast enough, it's far far far too
> |  general.  The examples I've seen so far make me think we should just
> |  be writing apache 2.0 in Perl and eval the config file on every hit.
> |...
> 
> ???
> 
> > After all _walks ?
> 
> Or perhaps you could not implement it as a container. Instead associate
> each directive with an array which contains the conditionals to be tested
> (environment variables). Then *any directive which is allowed within a
> conditional* can call a core routine which checks the conditionals in the
> array and returns OK/FALSE. The idea being to minimise the amount of extra
> processing for (a) directives which aren't allowed inside an <If> and (b) 
> minimise the amount of processing for directives which *are* allowed
> inside the <If>.
> 
> However I am quite happy for you do come up with a solution instead. 
> 
> //pcs
> 
> 
> 


Mime
View raw message