httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: hooks
Date Wed, 05 Jul 2000 05:41:32 GMT
> From: Life is hard, and then you die []
> Sent: Tuesday, July 04, 2000 6:51 PM
> On Tue, Jul 04, 2000 at 04:10:21PM -0700, 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.


View raw message