Ben Collins-Sussman <sussman@collab.net> writes:
> UTF-8 was the *plan*, as in, *someday*. If you look throughout our
> code, you'll find essentially zero regard for i18n, l10n, or UTF-8
> conversions. Nothing, nada, zip.
>
> Someday, this will be a big project. :-)
Yeah, that's why I intend to add some. It doesn't look like _that_
big a project, the main point is deciding who convers where. And if
we have decided that strings that go between the client and the svn
libs are UTF-8 encoded, and strings that go between the svn libs and
APR are not, then we have a fairly clean cut. It's just a matter of
inserting conversions wherever a client calls svn libs, or svn libs
call APR. (Natually, I'm thinking slices rather than code positions
here.)
Now, considering that the svn libs need to do conversions too, I'm
thinking that it would probably be a good idea to put the actual
conversion code in libsvn_subr. That would mean having to make an
exception to the rule "strings passed from client to svn libs are
always UTF-8" though, as the strings passed to the "encode as UTF-8"
function are of course not very likely to be UTF-8 encoded already. :)
So, would you agree that an utf.c in libsvn_subr is a good idea?
// Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 12 21:24:02 2002