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 work. >... > 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). Agreed. > 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. Cheers, -g -- Greg Stein, http://www.lyra.org/
