You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2002/05/12 00:55:35 UTC

Outch, or getting to the last mile

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


Re: Outch, or getting to the last mile

Posted by Greg Stein <gs...@lyra.org>.
On Sat, May 11, 2002 at 05:55:35PM -0500, William A. Rowe, Jr. wrote:
> Well, I'm ready to reverse my earlier position on uuid.

Woo!

> Here's the issue; we've recoded apr-iconv in terms of platform-neutral apr.

Cool.

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

Right. I've looked at using an alternative to md5 for the uuid stuff, but it
is no go. The specification states that UUID generation must use a
"cryptographically secure hash, such as MD5".

> 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

Ah. Excellent call. I really like this mechanism. ++1

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

We absolutely want to use Win32's native UUID mechanism.

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

Big time. Awesome.

Cheers,
-g

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

Re: Outch, or getting to the last mile

Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:

> At 04:27 PM 5/12/2002, brane wrote:
>
>> William A. Rowe, Jr. wrote:
>>
>> 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?
>>
>>
>> +1, assuming utf8 <-> wchar_t conversion is still available on all 
>> platforms.
>
>
>
> With a caviat... that needs to remain in apr.  We rely on utf8 <> 
> wchar on
> win32 internally.
>
> Folks requested that the symbols for utf conversion not be exported or
> publicly used, when I introduced them (relying on the apr_xlate_* family
> instead.)  Has this position changed?


If apr_xlate_* provides the functionality, that's fine.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/



Re: Outch, or getting to the last mile

Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 04:27 PM 5/12/2002, brane wrote:
>William A. Rowe, Jr. wrote:
>
>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?
>
>+1, assuming utf8 <-> wchar_t conversion is still available on all platforms.


With a caviat... that needs to remain in apr.  We rely on utf8 <> wchar on
win32 internally.

Folks requested that the symbols for utf conversion not be exported or
publicly used, when I introduced them (relying on the apr_xlate_* family
instead.)  Has this position changed?




Re: Outch, or getting to the last mile

Posted by Branko Čibej <br...@xbc.nu>.
William A. Rowe, Jr. wrote:

> Well, I'm ready to reverse my earlier position on uuid. 

[snip]

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

+1, assuming utf8 <-> wchar_t conversion is still available on all 
platforms.

-- 
Brane Čibej   <br...@xbc.nu>   http://www.xbc.nu/brane/