Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 26 Sep 2001 16:15:30 -0700
From: Aaron Bannert <aaron@clove.org>
To: dev@httpd.apache.org, dev@apr.apache.org
Subject: Re: [PROPOSAL] apr-client
Message-ID: <20010926161530.Z14683@clove.org>
References: <JLEGKKNELMHCJPNMOKHOEEHCEKAA.striker@apache.org>
 <20010926214644.CDBCF46DFF@koj.rkbloom.net> <20010926152142.K4050@lyra.org>
 <20010926153312.I21915@ebuilt.com> <20010926155218.M4050@lyra.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010926155218.M4050@lyra.org>;
 from gstein@lyra.org on Wed, Sep 26, 2001 at 03:52:18PM -0700

On Wed, Sep 26, 2001 at 03:52:18PM -0700, Greg Stein wrote:
> > FWIW, flood in httpd-test already has 80% of what Sander suggested.
> 
> Sander and I already talked about stealing code from flood and mod_proxy. :-)

*ahem* ;)

In all seriousness, I think we've already got most of the code we want.
(Flood already does or can do some of the things Sander suggested).

> > The major thing it is missing is bucket/brigade/filters - which is 
> > why I'm getting pissy about the API change because I want to move 
> > flood to this.  (It is also missing chunking and pipelining which I 
> > was working on when I got interrupted when I saw how httpd handles 
> > it and started to rewrite the input filtering.)
> > 
> > The one thing I would change in Sander's proposal is that I detest
> > callbacks.
> 
> It should not be hard to build it such that push or pull models could be
> used here.
> 
> There are four points of push/pull:
> 
> 1a) app pushes request into apr-client, which then transfers it onto the
>     network. this is like the output filter chain of httpd.
> 
> 1b) app gives a callback to apr-client, which it uses to pull data and
>     deliver it to the network. this is similar to httpd pulling data via the
>     input filter chain.
> 
> 2a) apr-client pushes response to an app's callback
> 
> 2b) app pulls response from apr-client as it becomes available
> 
> 
> An application can choose 1a or 1b, and 2a or 2b for how it handles the
> request/response process. The question boils down to "who is in control?" In
> 1a and 2b, the app is in control. In 1b and 2a, the library is in control
> (based on network conditions).
> 
> When Sander mentioned callbacks, he was really referring to 2a. (that aspect
> came up in our conversation; we didn't discuss 1b much).

I have no problem with either the push or pull methods, but I wanted to
make the point that flood could benefit from both request generation
brigades/filters as well as response filtering. Flood is designed
right now so that there are phases for both receiving and verifying a
response. We'd like to be able to throw in more than one verification
module (configurable at runtime) and not have to worry about double-copy
overhead and memory constraints.

> > And, I think the API would need to be a bit more formal.
> 
> Absolutely. That is why my previous email mentioned that I'd be happy to see
> a directory / cvs module get started so a roadmap could be created. I would
> want to see the API first, built from our expertise with the brigades and
> filtering systems, and with a lot of the ideas embodied in Neon's APIs.

+1
(once we get it rolling we can move this kind of discussion there and
start writing design docs)

> > And, in discussions with Roy, I think he was thinking a client
> > library should be a part of httpd not APR.  But, I don't care
> > one way or another.  -- justin
> 
> Nah. This has utility outside of httpd. Specifically, Subversion is an
> excellent candidate. I also know that Covalent has a similar library that
> they use internally ("apua", I believe). So that is candidate #2. And then
> you have your flood program for candidate #3. Of course, mod_proxy would use
> it, but that can fall under Roy's httpd placement model.

Justin: when you say "part of httpd" do you mean "a subproject of"?

I don't really care where it goes as long as it can be used independently
of the core httpd source.

-aaron