apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Outch, or getting to the last mile
Date Sat, 11 May 2002 22:55:35 GMT
Well, I'm ready to reverse my earlier position on uuid.

Here's the issue; we've recoded apr-iconv in terms of platform-neutral apr.
Ergo, we must bake apr before we are ready to put apr-iconv in the oven,
but that means we can't build apr_xlate_* into apr.

So, move apr_xlate_* into apr-util (along with dbm, xml, and ldap.)
Problem solved?  Not.

apr_md5_* requires apr_xlate_*.  Ok, off apr_md5_* goes into apr-util/crypto.
Problem solved finally?  Not.

apr_uuid_* on unix is based on apr_md5.  Now we are back to the old debate.
We've got to use it.

So my suggestion.  In apr, create an apr_os_uuid() stub for apr-util and the
'real' apr_uuid_* family.  Add APR_HAS_NATIVE_UUID.  Either that, or
reinvent the uuid for Apache.  However, this has one pitfall.  Win32 has code
that mutually protects all apps running on the same box from uuid clashes.
I don't really believe we want to lose that, so the first suggestion makes
a little more sense to me.

So all in all

apr/passwd/apr_md5.c  -->  apr-util/crypto/apr_md5.c

apr/misc/win32/uuid.c  ->  apr/misc/win32/os_uuid.c

apr/misc/unix/getuuid.c  -->  apr-util/misc/uuid_gen.c
[simply stubs for apr_os_uuid if APR_HAS_OS_UUID]

apr/misc/unix/uuid.c  -->  apr-util/misc/uuid_fmt.c

apr/i18n/unix/utf8_ucs2.c ->  apr/i18n/win32/utf8_ucs2.c [private]

apr/i18n/unix/xlate.c ->  apr-util/i18n/xlate.c

would this satisfy everyone?


View raw message