apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: [PROPOSAL] apr-client
Date Wed, 26 Sep 2001 22:52:18 GMT
On Wed, Sep 26, 2001 at 03:33:12PM -0700, Justin Erenkrantz wrote:
> On Wed, Sep 26, 2001 at 03:21:42PM -0700, Greg Stein wrote:
> > But that said, I'm am a BIG +1 on adding an http client library into the
> > ASF's APR project. Whether people want that to go into apr-util or into a
> > new apr-client, I'm not too concerned.
> 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. :-)

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

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

> And, the build process cleaned up.  And, more testing.
> Yadda, yadda, yadda.

Of course :-)

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

And then there are the ones we don't know about...


Greg Stein, http://www.lyra.org/

View raw message