Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 12446 invoked by uid 500); 5 Jul 2000 00:09:47 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 12422 invoked from network); 5 Jul 2000 00:09:45 -0000 X-Authentication-Warning: koj.rkbloom.net: rbb owned process doing -bs Date: Tue, 4 Jul 2000 17:10:26 -0700 (PDT) From: rbb@covalent.net X-Sender: rbb@koj.rkbloom.net To: new-httpd@apache.org Subject: Re: hooks In-Reply-To: <20000704165111.B29973@innovation.ch> 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 > > > If everybody is happy with lib/utils then I'll attempt to beat you to > > > it for the md5, sha1, base64, getpass, etc. > > > > I would still really like to see all of these files in APR. They all use > > APR types, and although the code is all common for all platforms, they are > > portability issues for most programs. By moving them into different > > directories within APR, we can enable and disable them at compile time. > > What portability issues? The ebcdic stuff is now in apr (ap_xlate, or so > I assume), and I can't think of any others. The EBCDIC stuff is still in ap_base64.c, but that is another issue. I was mainly thinking of the MD5 stuff with regards to portability, because some platforms have it and others don't. We actually took our code from FreeBSD, so we know they have this function. The other argument is that this is a bunch of VERY portable encryption code. Anybody who is trying to write a secure piece of portable software would most likely like to use some of these functions. Isn't this what APR is supposed to provide? The ability to write very portable software with one library. We can put all of these functions in lib/apr/encrypt or lib/apr/enocde (may be more precise) and be able to enable/disable them at compile time. I really think these are useful portable routines. > Last time I asked about > this, Greg was against moving them into apr and other-Bill was for it - > other than that nobody cared. I'm equally split on whether to put it in > apr or lib/utils. Count me on the side of APR. :-) I believe Manoj is against moving them into APR as well, but I don't want to speak for him. :-) > > At the very least getpass is a portability issue, and it doesn't always > > have common code, so it definately belongs in APR. > > Sorry, confused getpass with checkpass (which needs to be brought in from > apache-1.3) - you're right, getpass shouldn't be touched. ap_checkpass is validate_password, which can be found in apr/lib/apr_md5.c. :-) See above for why this function shouldn't be moved out of APR. It should be moved to apr/encode/apr_validate.c IMHO though. > > Which things are included in the etc? I would like to be VERY careful > > about what we move out of APR, because some of the functions in the lib > > directory are portability issues, and not cruft for APR. > > Etc referred to stuff in ap and main: ap/ap_cache, ap/ap_hooks, and the > main/util* stuff. This stuff I would like to see moved to lib/util. This is code that is very suited for Apache, but isn't really written to be useful to things other than web servers. That is where I see the biggest difference. Ryan _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 -------------------------------------------------------------------------------