httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: dev question: apreq 2 as a filter?
Date Wed, 28 Aug 2002 02:38:24 GMT
Joe Schaefer wrote:
> "Issac Goldstand" <margol@beamartyr.net> 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.

Yes, the user API should be very simple and transparent. If you call 
$q->parse, which you really don't need it, as it'll be done behind the 
scenes, it'll block till it gets all the data.

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

I'm fine with any of your decisions. My point is that end user should 
have a similar experience to apreq 1, in terms of simplicity of usage 
and ideally basic API (param, upload, etc) shouldn't change. If it does, 
we (the perl side) will make the necessary adjustments so it'll stay the 
same. So no problem here.



__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Mime
View raw message