httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: hooks
Date Wed, 05 Jul 2000 20:35:04 GMT

> > The EBCDIC stuff is still in ap_base64.c, but that is another issue.
> That has to change anyway to use ap_xlate.


> As has been said, these are completely portable functions across any
> platform/compiler/etc, with the exception of the non-binary versions
> of update - those need to use ap_xlate, at which point the stuff
> becomes fully portable.

The problem is what do we mean by "portable".  Yes, the C code is
portable.  The problem is that there isn't currently an encoding function
on all platforms.  If we take the stance that any inheritantly portable
code does not belong in APR, then we basically have to remove all of the
apr/lib directory.  All of that code is inherantly portable.  But wait,
look at what that code is.

pools  --   can't remove those, APR relies on those.
string functions --  things like ap_pstrdup and ap_pstrncpy.  We re-wrote
                     those to be more portable, and to make more
		     sense.  According to the definition that is keeping
		     the encoding stuff out of APR, these aren't portable
signals --  not all platforms used the same API or had the same
            semantics.  We re-implemented to make it all common.

apr_getopt (from misc)  --  all platforms didn't have the same semantics,
			    we re-implemented.

APR wasn't designed to provide only functions that couldn't be written
once for all platforms.  It was designed to provide a common API for all
platforms.  Not all platforms have crypt, not all platforms have md5, not
all platforms have sha1.  Shoot, Windows doesn't have any of them.

These belong in APR, because they implement the same feature on all
platforms.  That makes them portable, and it makes them a candidate for a
portability run-time.  This does not make APR a kitchen-sink, it doesn't
even expand APR's design goals.

If we want APR to decide on one encoding algorithm, and use it on all
platforms, then fine, put one encoding algorithm in APR and the rest in
lib/util.  This sounds stupid to me though.  APR needs a way to encode
data on all platforms without relying on another library.  Unless crypt is
available on all platforms (it isn't), then this is something APR should

> Btw., does anybody disagree with changing the update functions in
> md5 and sha1 to ap_MD5Update_ascii(), ap_MD5Update_binary(),
> ap_SHA1Update_ascii(), and ap_SHA1Update_binary()? I.e. to better
> reflect which are ascii and which binary (the ascii forms first
> translate the characters as necessary to ascii). And similarly
> for ap_base64. Currently we have ap_SHA1Update() and
> ap_SHA1Update_binary() in 1.3.


> I agree. This is boiling down to the previous (and I think undecided)
> discussion of what should go into APR. I have nothing against putting
> md5, sha1, and base64 into APR - I'm just noting that I think your
> portability argument isn't valid.

I think I explained the portability issue a bit better above.  Do you
think it's valid and makes sense now?

> I quite aware of what ap_checkpass contains :-)
> A number of changes were made in the 1.3 code base last July, but those
> changes never got brought forward to 2.0 (the snapshot was taken just
> before). As part of the move I intended to bring those changes forward.
> Btw., apr_validate.c is too generic, IMHO - validate what?
> apr_checkpass.c is clearer. Or apr_validate_pw.c . But that's a nit.

Names are a VERY minor thing to me.  I usually don't come up with the
right one, so choose whatever you want.  I wasn't aware that there were
changes made to validate_passwd in 1.3 that weren't in 2.0.  By all means,
this needs to be updated.  From your original note it looked like we were
about to duplicate some logic.  :-)


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message