apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: SHA1 and Base64
Date Tue, 28 Nov 2000 05:57:53 GMT
On Mon, 27 Nov 2000, Greg Stein wrote:

> On Mon, Nov 27, 2000 at 04:26:46PM -0800, rbb@covalent.net wrote:
> > 
> > The new-httpd group has discussed putting SHA1 and Base 64 encoding
> > schemes into APR.  This has met with some resistance in the past, but it
> > really needs to be discussed and decided here.  So, can these go in the
> > passwd directory of APR?
> 
> <IMO>
> 
> They do nothing for portability. They should go into the new "aputil"
> library in Apache. If we see a big demand for utility functions (rather than
> portability stuff), then we can extract aputil.
> 
> </IMO>
> 
> Heck, I never thought the inclusion of MD5 was appropriate. That has nothing
> to do with portability either, and the other parts of APR don't need it.
> About the only reason is that the MD5 code does translation at the same
> time. But that is still just a layer on top of APR... nothing in APR uses
> MD5 itself.
> 
> (hashes, tables, arrays are portable, but APR itself needs those)

I just don't understand this argument, I'm sorry.  The whole point of APR
is to help people port their code to different platforms.  If you want to
get rid of any type that isn't needed by APR itself, then please lets be
consistent.

APR never uses tables, at least the only place I see tables is in the
tables.c file.

APR only uses arrays in the canonical stuff, and I'm pretty sure it could
be removed easily.

APR doesn't currently use hashes, but there is a comment that the userdata
should be replaced with a hash.

It is my own opinion that SHA1 and Base64 encoding are inherently
portable, but that doesn't make it a non-issue for portability
run-times.  These are features that useful to applications besides
servers.

I just took a quick look at NSPR, which is what APR was originally based
on, and they have a linked list structure.  Linked lists are also
inherently portable.

These don't belong in aputil, for one thing aputil has never been defined
as far as what it is.  I had always envisioned it as more of a user-agent
type of library, which handled URI issues.  What is there now, is database
code, which in my mind is at a higher level than SHA1 and Base64.

The question we really need to decide, is what makes code an issue for a
portable run-time.  Is it that the code is different on different
platforms, or that the code is useful for many different kinds of programs
and has some potential issues on different machines.

I believe the latter is the correct definition for a portable run-time,
and that SHA1 and Base64 encoding fit this definition.

Ryan

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




Mime
View raw message