apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: SHA1 and Base64
Date Tue, 28 Nov 2000 07:18:08 GMT
On Mon, Nov 27, 2000 at 09:57:53PM -0800, rbb@covalent.net wrote:
> 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.

Key word: PORT

APR isn't a kitchen sink of functionality. It is a portability library.

Didn't we just get done talking about this?

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

I have no problem being consistent. If tables aren't used, then yah... I'm
fine with seeing them moved out of APR. Hell, if it weren't for all the
legacy Apache code that used tables, I'd dump them in favor of apr_hash_t.

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

Well, we shouldn't make our life difficult just to toss a type. But if the
arrays don't make sense, then yah. I have no problem with tossing them, too.

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

It really should. I'm probably going to change it within the next few days
because I'd like to use non-string keys for some userdata.

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

Useful != assisting-with-porting

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

So? That's NSPR. We're talking about APR here :-)

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

You guys extracted much of that code from Apache and created a library
called "apua". That is not the same as yanking the non-HTTP-server specific
stuff from Apache and placing it into aputil.

Yes, aputil isn't defined YET, but the discussions over the past year about
creating a library have all centered around "move src/ap/ into
lib/something". That something is now aputil.

> What is there now, is database
> code, which in my mind is at a higher level than SHA1 and Base64.

We can stratify and create as many layers in Apache as we want to put up
with. But when we're talking about a *portability* library, then it should
focus on just that.

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

By this argument, we should also include compression code, SSL encryption, a
DBM implementation, XML utilities, hooks, buckets, and some date formatting
and parsing functions. :-)

All of those are used in Apache, and I could see using all of them in SVN.
But I don't want to see all that lumped into APR. It doesn't suit APR's
goals of assisting with portability.


Greg Stein, http://www.lyra.org/

View raw message