Return-Path: 
 <apreq-dev-return-443-apmail-httpd-apreq-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org
Received: (qmail 29794 invoked by uid 500); 27 Aug 2002 16:55:58 -0000
Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:apreq-dev@httpd.apache.org>
List-Help: <mailto:apreq-dev-help@httpd.apache.org>
List-Unsubscribe: <mailto:apreq-dev-unsubscribe@httpd.apache.org>
List-Subscribe: <mailto:apreq-dev-subscribe@httpd.apache.org>
Delivered-To: mailing list apreq-dev@httpd.apache.org
Delivered-To: moderator for apreq-dev@httpd.apache.org
Received: (qmail 55123 invoked from network); 27 Aug 2002 10:37:50 -0000
Message-ID: <001701c24db5$b4514700$8100a8c0@FMENC001DEV>
From: "Issac Goldstand" <igoldstand@followmecorp.com>
To: "Stas Bekman" <stas@stason.org>, "Joe Schaefer" <joe@sunstarsys.com>
Cc: "William A. Rowe, Jr." <wrowe@rowe-clan.net>,
   "Issac Goldstand" <margol@beamartyr.net>,
   "apreq list" <apreq-dev@httpd.apache.org>
References: <Stas Bekman's message of "Fri,
 23 Aug 2002 00:36:32 +0800"> <m33ct8f3oe.fsf@mumonkan.sunstarsys.com>
 <200208212349.40583.chatgris@mediapow.com>
 <m3it23edez.fsf@mumonkan.sunstarsys.com> <3D647453.7030704@stason.org>
 <m3bs7vdjum.fsf@mumonkan.sunstarsys.com> <3D651310.3050008@stason.org>
 <5.1.0.14.2.20020822123542.02919dc8@pop3.rowe-clan.net>
 <m3n0red9g4.fsf@mumonkan.sunstarsys.com> <3D65AF9D.7060908@stason.org>
 <m3znveb2ld.fsf@mumonkan.sunstarsys.com> <3D65CA9A.4050706@stason.org>
 <m3sn16aywo.fsf@mumonkan.sunstarsys.com>
 <5.1.0.14.2.20020823035453.02bf93b8@pop3.rowe-clan.net>
 <3D6602E1.9070600@stason.org> <m3y9aw7ldj.fsf@mumonkan.sunstarsys.com>
 <5.1.0.14.2.20020825004851.02a71ea0@pop3.rowe-clan.net>
 <m3n0rb58og.fsf@mumonkan.sunstarsys.com>
 <m3it1z568t.fsf@mumonkan.sunstarsys.com> <3D69D3C0.5000609@stason.org>
 <m3fzx13mh3.fsf@mumonkan.sunstarsys.com> <3D6AF21E.4090709@stason.org>
Subject: Re: dev question: apreq 2 as a filter?
Date: Tue, 27 Aug 2002 13:37:10 +0300
Organization: FollowMe Corporation
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


----- Original Message -----
From: "Stas Bekman" <stas@stason.org>
To: "Joe Schaefer" <joe@sunstarsys.com>
Cc: "William A. Rowe, Jr." <wrowe@rowe-clan.net>; "Issac Goldstand"
<margol@beamartyr.net>; "apreq list" <apreq-dev@httpd.apache.org>
Sent: Tuesday, August 27, 2002 6:29 AM
Subject: Re: dev question: apreq 2 as a filter?


> Joe Schaefer wrote:
> > Stas Bekman <stas@stason.org> writes:
> >
> >
> >>Joe Schaefer wrote:
> >>
> >>>Joe Schaefer <joe@sunstarsys.com> writes:
> >>>
> >>>[...]
> >>>
> >>>
> >>>
> >>>>I think the apreq filter can/should operate in a completely
> >>>>transparent way, since all it has to do is read a copy of the buckets
> >>>>into the apreq_list _as the upstream_ _filters dictate_.  Every time
> >>>>our filter is invoked, it can make a stab at parsing the apreq_list
> >>>>data, so the list should never get very big.
> >>>
> >>>
> >>>Um, you may need to s/upstream/downstream/g in everything I wrote in
> >>>the aforementioned post.  It'd be nice if what I write actually matched
> >>>the picture in my head :-)
> >>
> >>The things that I see weird about this is that the normal filter is not
> >>supposed to call ap_get_brigade more than once.
> >
> >
> > It is, I just didn't spell it out.  In the filter section, there
> > should've been a
> >
> >   (g) content-handler calls ap_get_brigade again, and winds up
> >       engaging the apreq filter again.  The filter picks up where
> >       it last left off.
>
> it's really the apreq part of the content handler is the one that calls
> ap_get_brigade, the user code only calls apreq_*() calls and shouldn't
> have to do anything with ap_get_brigade.

Wait - I thought that the *user* calls ap_get_brigade() which causes data to
pass through the apreq filter?  The only time apreq should directly call
ap_get_brigade() on its own is in reponse to a query made by the "warehouse
manager" if the entry in question is not marked "in stock"...

> >   (h) the content-handler repeats (g) until it has whatever portion
> >       of the POST data it wants.
> >
> >   (i) the content-handler wants some data from our warehouse.  The
> >       apreq library calls apreq_request_parse to complete the parsing
> >       of POST data (should it need to), and *then* fetches the data
> >       requested.
> >
> > In the model I'm  presenting, the apreq filter *never* consumes
> > more data than the downstream filter has requested of it.  If
> > the downstream filter asks for 2KB, we should read in at most
> > 2KB, and use the filter's state mechanism to keep track of where
> > we left off.  However, as soon as the content-handler wants something
> > from the warehouse, it must abandoned any future claims to the remaining
> > POST data, since apreq needs the full amount in order to access the
> > warehouse and may call apreq_request_parse (prior to any access) to
> > enforce that.
>
> ok. just need to remember to apreq now is really two parts.

Even 3 parts according to my approach - the filter, the parser and the
warehouse manager.

> > [...]
> >
> >
> >>Not sure why have you added a note about s/upstream/downstream/g, any
> >>filter cares only about the upstream filter (which may block), because
> >>that's where the data is coming from. it passes through the data to the
> >>downstream filter, but it doesn't care about it.
> >
> >
> > Does this clear things up now?
>
> I guess so. Having a spec will help, as the current emails with
> scenarios are getting longer and longer and many repeat themselves using
> different wordings :)
>

Agreed.

  Issac