At 05:12 PM 3/29/2005, Roy T.Fielding wrote: >IMO, delete apr-iconv and let installers use the system-supplied >library.
Respectfully, I don't think we can do so in apr-util 1.x. The apr-util 2.0 release is the next major bump for deprecating interfaces, and we would have to alert users that it's as likely as not that apr_xlate will return APR_ENOTIMPL more often than it had previously done. Nothing is stopping us from moving up to apr-util 2.0 tomorrow, of course. Now let me explain why we can't do this using Win32's internal charset translation. apr_xlate's api was too transparent around iconv. The Win32 API uses an all-or-nothing approach, returning the number of bytes required to represent the translated text if the results would not fit in the user supplied buffer. The iconv implementation will perform a partial translation, incrementing both the source and destination string pointers to the end of the successfully translated text. Because the source and destination code pages may match in bytes per character, may be a multiple or fraction (e.g. ascii<>unicode) or even multibyte representations, there is no way for the Win32 implementation to reinvoke w/the appropriate length of the source text, except by backing up one byte at a time till we have a fit. I understand there is a COM equivalent on Win32 that does perform partial translations, but adding the COM overhead would be painful, and surely less efficient than fitting iconv on win32. My bottom-line proposal is to support iconv 2.0.3 on Win32, in the framework of an iconv project. I'm soliciting input from the various platform maintainers of that long-neglected code. Again I don't see this change as realistic until apr-util 2.0. Bill
