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:35:56 GMT
And P.S.  I'm not sure, but there may exist modules that don't like having
their configs changed after the _walks are done and some methods have been
invoked.

Dean

On Mon, 18 Aug 1997, Dean Gaudet wrote:

> 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