Return-Path: Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org Received: (qmail 80822 invoked by uid 500); 27 Aug 2002 23:40:41 -0000 Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list apreq-dev@httpd.apache.org Received: (qmail 80798 invoked from network); 27 Aug 2002 23:40:41 -0000 To: "Issac Goldstand" Cc: "Stas Bekman" , "Issac Goldstand" , "William A. Rowe, Jr." , "apreq list" Subject: Re: dev question: apreq 2 as a filter? References: <200208212349.40583.chatgris@mediapow.com> <3D647453.7030704@stason.org> <3D651310.3050008@stason.org> <5.1.0.14.2.20020822123542.02919dc8@pop3.rowe-clan.net> <3D65AF9D.7060908@stason.org> <3D65CA9A.4050706@stason.org> <5.1.0.14.2.20020823035453.02bf93b8@pop3.rowe-clan.net> <3D6602E1.9070600@stason.org> <5.1.0.14.2.20020825004851.02a71ea0@pop3.rowe-clan.net> <3D69D3C0.5000609@stason.org> <3D6AF21E.4090709@stason.org> <001701c24db5$b4514700$8100a8c0@FMENC001DEV> <3D6B5F8E.6030409@stason.org> <005b01c24e26$bee13830$1a0aa8c0@followmecorp.com> From: Joe Schaefer Date: 27 Aug 2002 19:41:42 -0400 In-Reply-To: "Issac Goldstand"'s message of "Wed, 28 Aug 2002 03:04:31 +0300" Message-ID: Lines: 46 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N "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