Hi all,
I wish to propose a new library: apr-client.
It is basically a http client library. I see
a direct use for at least three projects:
- mod_proxy (which has most of the code in it),
- flood (to do more flexible testing, for example
with authentication, or even ssl client auth),
- subversion (which is currently using neon).
The library is going to be based on apr
and apr-util, and will have an optional dependency
on openssl (through a --with-ssl[=path] switch).
Features:
- sessions
- request building
- response parsing
- pipelining
- authentication support
- filters
- like ssl, gz, chunk
Callbacks will be used to drive events (like responses,
or the need for auth information).
The library should make heavy use of buckets/brigades,
I dare even say the request building is a thin wrapper
around those.
Requests supported should be all HTTP requests and
the DAV extensions.
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).
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).
Well, this mail isn't the extensive description I wanted
to give*, but surely enough to get some feedback.
Sander
*) Am a bit distracted for some reason.
