Karl Fogel wrote:
>>As far as I know, the apr-iconv issues remain. There are two _really_
>>big problems: a) apr-iconv relies on symbolic links to implement charset
>>aliases, which obviously won't work on Windows; and b) it can't do
>>transliteration like GNU libiconv does. The first problem can be fixed
>>easily, the second is much harder.
>>
>>
>
>Okay, gotcha.
>
>The transliteration issue is not a showstopper. We had a "graceful
>degradation" strategy that worked well enough, and is compatible with
>transliteration being added incrementally, so we can easily proceed
>without translit.
>
O.K., we'll do this in short steps then.
> For example, we could move our degradation strategy
>down into APR, by adding an APR_XLATE_TRANSLIT flag right now. At
>first, it would just represent non-recodeable bytes in some formal way
>(with '?' like in svn_utf_utf8_to_native() or whatever), but over time
>it could gradually be taught to really transliterate more and more.
>
>That's not a lot of work, so I wouldn't feel to bad about the
>wheel-reinvention aspect.
>
Understood.
>So if the symlink issue is easy to fix too, it looks like there are no
>substantial obstacles here...
>
>
Fixing the symlink is simple, I'd just have to add another aliasing
mechanism -- probably a text file that defines the aliases, which would
be read if the shared lib isn't found, so that adding aliases would
still not require a recompile or relink.
Well, here goes...
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 11 22:55:39 2002