httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: hooks
Date Wed, 05 Jul 2000 09:57:27 GMT
On Tue, Jul 04, 2000 at 05:10:26PM -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.
> 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.

I believe the result of that conversation was just to always use our
functions rather than trying to rely on per-platform MD5 libraries.

> 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.

MD5 and SHA1 are "hash" functions. Very far from encryption or even
encoding. We should avoid calling them anything close to encryption because
that would open a huge can of worms :-)

Both hash functions are inherently portable, which makes their placement in
APR dubious.

Given our move towards shifting some functionality over to lib/util, then I
believe that is a good location for these generic, inherently-portable
suites of functionality.

> > 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.

Correct. APR should be our portability-enabler rather than a kitchen sink of
useful functions. Keeping a tight, clean focus on that will keep APR on
track to being an excellent tool.

[ note: Subversion ( has definitively selected APR as
  a base library. their first milestone is September, where we'll see a
  non-Apache application ship using APR. whee! ]

Now if lib/util becomes "interesting" to package, then we can make that
choice later. IMO, there are already too many "kitchen sink" libraries out
there. Lets avoid that space. APR can be incredibly successful by simply
offering portability to apps.

> > > 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.

What is the rule for moving something into lib/util? What is the rule for
NOT moving it? I am unclear on this. Do we simply say anything that happened
to have been named "util_*" gets moved? Why not mpm_common? It is a neat
little set of common functions that an MPM might use. Is util_uri really a
non-web-server thing that is destined for lib/util?

Meta-point here: if we're going to start creating directories for this and
that, then *please* make sure that a directory has a well-defined meaning.
Otherwise, it could create confusion when people think, "dang. where does
that module live? in the utility directory? oh, wait, that is an HTTP
utility, so it must be in the main directory. oops. but it applies to any
networking protocol, so it must be in the netutil directory."


Greg Stein,

View raw message