httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@raleigh.ibm.com>
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.cutil_filter.c
Date Fri, 15 Sep 2000 18:00:06 GMT
rbb@covalent.net wrote:
> 
> > Is anybody opposed to extending what Ryan committed with something
> > like the following?
> >
> > 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
> 

This is not as easy for the admin as the syntax Jeff proposed.  (More
lines to code which must be in sync && more directives) == more rope for
the admin to hang him/herself with.

> 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.
> 

Either way, the onus would be on the module implementor.

> > 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.  

Agreed.  

> What
> happens if a filter doesn't implement any arguments?  

It doesn't register a hook to parse arguments.

> Does the core still
> try to pass those arguments to the filter?  

No, it can't - no hook.  If the core sees that there are arguments and
no hook to parse them,
it should complain about the AddOutputFilter statement.

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

A module/filter lets the core know that it can handle arguments by
registering a hook to
parse the filter arguments.  The core should complain if there are
arguments but no hook registered.  The module/filter should complain if
it doesn't like its arguments.

Greg

Mime
View raw message