Branko Čibej <brane@xbc.nu> writes:
> *sigh* Why don't you just ask, instead of hinting? :-)
Seriously, you want a non-sarcastic answer?
Because you do enough around here that I was too shy to ask outright :-).
A hint is lighter, so you can just ignore it if you want, or maybe
reject it using your own custom XML tag.
> 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. 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.
So if the symlink issue is easy to fix too, it looks like there are no
substantial obstacles here...
-Karl
---------------------------------------------------------------------
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:18:40 2002