Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
Date: Wed, 5 Jul 2000 08:01:45 -0700 (PDT)
From: rbb@covalent.net
To: new-httpd@apache.org
Subject: Re: hooks
In-Reply-To: <20000705025726.N29590@lyra.org>
Message-ID: <Pine.LNX.4.21.0007050737070.1138-100000@koj.rkbloom.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


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

Yes, but this doesn't reduce the need for portability here, and it doesn't
reduce the argument that not all platforms have an encryption/encoding
routine.

> > 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 :-)

Considering that both the md5 and sha1 files refer to them encoding data
multiple times, I think we are safe calling them encoding functions.

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

The placement in APR isn't dubious.  They are very useful portable
functions.  These are also functions that we have needed, and used
extensively.  I really don't see what the problem is as long as their
compilation can be turned off easily.  It can, by adding a simple flag to
the configure stage.

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

We don't even have lib/util yet.  We have been talking about it for
months, but nothing has ever been done, so I don't see how we can say we
have made that move.  Putting a new library in lib/util also implies that
this library will have it's own build system.  We can not just put a bunch
of files into a lib subdirectory and tie it into Apache's build system.

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

APR is a very focused project.  It's goal is to provide a set of functions
to help make programs portable.  This does not mean that all code that is
in APR must be inherently non-portable.  It just means that all code in
APR must be portable.

> [ note: Subversion (subversion.tigris.org) 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! ]

Sorry, they are too late.  :-)  I know of at least one closed source
application already using APR.  No, I'm not the one writing it.  I haven't
announced that it is being used or who is writing it, because the project
isn't finished.  :-)

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

But offering a small set of encoding functions could be argued to provide
portability.  Consider the trouble Apache had getting encoded passwords
into the Windows version.  Not all platforms provide ANY scheme to
encrypt/encode data.  This is a useful function, and it belongs in 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?

Things that are moved to lib/util, should be those functions that would be
useful to have outside of the webserver.  If they only make sense inside
of Apache, then the function doesn't belong in lib/util.  It belongs in
ap/.  As far as the util_* functions, if we remove the reliance on the
request_rec and ap_log_error* from the few functions that require it, then
yes those functions become VERY useful outside of the webserver.  Imagine
a small app wanting to make a web request or to parse a URI.  Having
util_uri would go a long way to making that easier.  Some of the util_*
files shouldn't be moved, they should be removed from the server
completely.  For example, util_script.  This file needs to start being
merged into mod_cgi[d], and the remaining parts need to be moved into
modules/common (a nonexistant directory, for functions needed by multiple
modules.  This would always be compiled into the server).

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

Of course.  :-)

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------