Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <new-httpd@apache.org>
Subject: RE: hooks
Date: Wed, 5 Jul 2000 00:41:32 -0500
Message-ID: <000801bfe644$3cbf2e30$345985d0@corecomm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: <20000704165111.B29973@innovation.ch>
Importance: Normal

> From: Life is hard, and then you die [mailto:ronald@innovation.ch]
> Sent: Tuesday, July 04, 2000 6:51 PM
> 
> On Tue, Jul 04, 2000 at 04:10:21PM -0700, rbb@covalent.net wrote:
> > 
> > > 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. 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.

Ok... APR being APR, and we had very, very little in the way of ap code
left, I strongly felt that should move.  I believed it should become part
of APR.

In hindsite, I realize why many were against this.  And I think, given
what everyone is suggesting for all the "module helper" code, that there
is room for a lib/aputil style library.  The existing ap stuff belongs
there, and so should all the xml stuff.

The difference?  No lib/aputil stuff should EVER change from processor
to processor, compiler to compiler, or os to os.

If it isn't that generic, then it's a portability problem (al la APR).

And if it is truly platform process or security model dependent, than
it belongs in the MPM or the potential future SMM.

Bill