Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 7507 invoked by uid 500); 26 Sep 2001 21:45:54 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 7457 invoked from network); 26 Sep 2001 21:45:53 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Ryan Bloom Reply-To: rbb@covalent.net Organization: Covalent Technologies To: dev@httpd.apache.org, "Sander Striker" , Subject: Re: [PROPOSAL] apr-client Date: Wed, 26 Sep 2001 14:46:44 -0700 X-Mailer: KMail [version 1.3] Cc: References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20010926214644.CDBCF46DFF@koj.rkbloom.net> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wednesday 26 September 2001 02:14 pm, Sander Striker wrote: There is supposed to be an http client library as a part of apr-util. It's just that nobody has actually written it yet. I would prefer to not create another library for this, because this client lib was one of the reasons that apr-util was created in the first place. Ryan > 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. -- ______________________________________________________________ Ryan Bloom rbb@apache.org Covalent Technologies rbb@covalent.net --------------------------------------------------------------