httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <>
Subject Re: dev question: apreq 2 as a filter?
Date Tue, 27 Aug 2002 23:41:42 GMT
"Issac Goldstand" <> writes:


> > the user of apreq() generally has no idea that ap_get_brigade() exists
> > at all. It just calls apreq_*() methods and the handler part of the
> > apreq calls ap_get_brigade.
> >
> > Think of it this way: the mod_perl 1.0 handlers using Apache::Request
> > should work under 2.0 unmodified. Now you get the idea.
> No, quite the contrary, you proved my point...  Consider the two possible
> scenarios:
> 1) Old apreq_1-style: A simple handler calls $q->parse, or
> $q->param('somevalue').  In this case, the user is making a request from the
> "warehouse manager".  If the entry is not "in stock", apreq will continue to
> call ap_get_brigade() until the warehouse manager can return something
> (either a value or an error if the parser set "warehouse full" in response
> to EOS).
> 2) New Apache 2-style:  A more complex handler or filter wants to start
> reading in the post body.  Since content-handlers are supposed to read the
> data, a programmer might call ap_get_brigade() on his own.  

Or s/he might not, which is certainly the case for the current user 
base.  It is important that we not *force* them to deal with the 
additional complexity that a filter-based implementation will require.
If they *want* to, that's a different story :-).  That's what I see 
Stas as saying here.

btw- let's not call our existing API "apreq 1" style.  I'm very 
happy to consider completely revamping our current implementation,
and even broadening the scope of apreq beyond httpd.  ( Based on
the dev@httpd comments so far, it looks to me like the parser-related 
code may get "generified" and wind up going in an APR-* project. 
I'm cool with that :-)

However, forced modifications to the core API aren't likely to get 
my vote.  To be specific, I'd be against any implementation that 
would *require* significant modification of the existing test suite.
So far, I don't see any problem here, and based on the discussion so
far, I'm not expecting this will ever become a problem.

Joe Schaefer

View raw message