Return-Path: Delivered-To: apmail-apache-cvs-archive@apache.org Received: (qmail 94433 invoked by uid 500); 28 Nov 2000 15:18:38 -0000 Mailing-List: contact apache-cvs-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list apache-cvs@apache.org Received: (qmail 94400 invoked by uid 500); 28 Nov 2000 15:18:37 -0000 Delivered-To: apmail-apache-2.0-cvs@apache.org Date: Tue, 28 Nov 2000 07:20:36 -0800 (PST) From: rbb@covalent.net X-Sender: rbb@koj.rkbloom.net To: new-httpd@apache.org cc: apache-2.0-cvs@apache.org Subject: Re: cvs commit: apache-2.0/src/lib/aputil README In-Reply-To: <20001128070144.13983.qmail@locus.apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > FEATURES: > > * apu_dbm: a generic interface for talking to different DBM > implementations > > * buckets: a set of data structures and functions that embody a > design for high performance I/O when the data may need to be > manipulated between generation and delivery. > > * hooks: a type-safe mechanism for creating a loosly-coupled > invocation system. > > * SHA1: functions to generate SHA-1 hashes > > * base64: functions to perform Base-64 encoding > > * URI: functions to manipulate URIs > > * XML: functions and data structures for handling XML This list feels like a kitchen sink. It looks like anything that Apache uses that isn't a part of the protocol handling. I dislike that a lot. If we are going to create a utility library, then it really shouldn't be a kitchen sink, it should have a well defined scope. This may mean that we end up with a couple of different utility libraries, or that we decide that we have four or five really small libraries that aren't related, and really can't survive on their own. BTW, SHA1 and Base64 encoding is currently being discussed on APR's dev list. The new-httpd developers have discussed this a few times, and the decision was always split. APR has it's own developer list now, and they deserve the right to look at this issue as well. I am still hopeful that this code will move to APR, and if it does then it should not move to aputil. If it doesn't, then it should move to a logical place in aputil. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------