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:41:20 GMT
On Wed, Sep 26, 2001 at 11:14:05PM +0200, Sander Striker wrote:
> Hi all,
> I wish to propose a new library: apr-client.

btw, I'm +1 on all points in here. Sander and I talked about this quite a
bit last night over IRC. I'm hoping for a general go ahead, a creation of a
STATUS and or roadmap/design [for apr-client], and then being able to dump a
bunch of stuff in there.

Note that I believe a simple client could be scrapped together in a couple
evenings. It could support sessions, pipelining, multithread, brigades, and
filters. Adding the auth, SSL, and response [XML] parsing is the bulk of the

> The filters are a nice area for code reuse.  The logic
> for the client is ofcourse reversed, so we can have
> a chunk filter on the request side and a dechunk on the
> response side.  This is just an example, replace
> chunk/dechunk with gzip/unzip and you have another.
> Same goes for ssl.  This way the same code gets used in
> multiple places which results in more extensive testing
> of this code (which is a nice side effect).

This would be good. However, I believe that it would probably be a good
amount of work to convert Apache's filters over to use apr-client's filters.
IMO, the latter's filter system will be a bit simply (in particular, NO
references to things like f->r and f->c). That implies a design difference
in the two systems.

So: excellent goal, but some recognition of the work is needed, too.

> You might ask yourself why the world would need yet
> another http client library.  Well, there seem to be
> only two good ones: curl and neon.  Curl is bloated
> (has ftp, gopher, etc support and is more a general
>  network client library).


> Neon is good, but LGPL.  Also,
> it doesn't tie in nicely with apr (example is malloc/free
> usage in it, which requires the user to malloc a chunk
> of mem, fill it, pass it to neon which then frees it).

The license is a big one for me (having apr-client and its ASF license means
we could replace proxy code with it; LGPL is a tougher decision for bundling
with ASF code). The integration isn't so big in my mind, but an APR-based
library would certainly eliminate a lot of dupliation (prolly 40% of neon
deals with stuff like allocation, strings, md5, base64, etc). And it would
also enhance portability. Also, Neon does not yet support pipelining (Joe
intends to, but it will be a big chunk of work). Those four items (license,
reduce dup, pipelining, portability) push me towards the +1 here.

That said: Neon is an excellent library. I do and would continue to
recommend it to people. I don't see SVN switching away from it for 1.0. But
post 1.0, picking up the pipelining and the tight APR integration will be
big win. [unless apr-client somehow managed to stabilize really fast]

I just think that the ASF projects could use it, and I think getting a
nicely licensed, fully capable client library would be great.


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

View raw message