httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c util_filter.c
Date Fri, 15 Sep 2000 18:59:43 GMT
rbb@covalent.net writes:

> > AddOutputFilter INCLUDES                                 \
> >                 BUCKETTRACE(--format text --per-line 80) \
> >                 XLATEOUT                                 \
> >                 BUCKETTRACE(--format hex --per-line 32)
> 
> Yes, I am.  This puts way too much in one directive.  This can be solved
> by having the module that implements BUCKETTRACE also have it's own
> directive.
> 
> I am thinking something like:
> 
> AddOutputFilter INCLUDES BUCKETTRACE XLATEOUT BUCKETTRACE
>
> BucketTraceSetup call1 --format text --per-line 80
> BucketTraceSetup call2 --format hex  --per-line 32
> 
> With some very simple module magic, you can easily associate the Setup
> with the call to the BucketTrace filter.  This puts the onus on the module
> implementor to allow setup for their module.

Hmmm... I like the FILTERNAME(params) syntax a lot better and I really
don't like the idea of each module which needs instance-specific
parameters having to invent that type of processing.

On the other hand, a really good attribute of the style you propose is
that the existing directory config support takes care of it.  That is a
problem with the FILTERNAME(PARAMS) syntax.

> > The string inside parens would be stored as-is (raw) in f->params.  If
> > no string was specified, f->params would be NULL.
> 
> AddOuputFilter should be very simple, not trying to do too much.  What
> happens if a filter doesn't implement any arguments?  Does the core still
> try to pass those arguments to the filter?  

Not a problem...  f->params (or hook argument or whatever) would be
NULL, of course.

>                                             The core can't determine if
> the filter takes arguments, so we can't return any kind of error to the
> user.

That's essentially the same problem as the user specifying bogus
arguments... There is no way to check ahead of time.  Using the
dirconfig infrastructure takes care of that.

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message