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?
Bill
