=?Windows-1252?Q?Jes=FAs_Torres?= <[EMAIL PROTECTED]> writes:
> I think that the Unicode support eradicate the problems with the characters
> set and do the exchange of information between users more easy.
I just want to point out that naive unicode support is dangerous. This
is because there are many characters that have several equivalent
representation in Unicode. One must use unicode + some
canonicalization rules. Perhaps the conclusions of the international
dns working group in the IETF (whatever that turns out to be) will
apply to international file names as well. I don't know how W*ndows
NT, Plan 9 and Solaris (the OS:es I have heard reports on support for
unicode filenames, sorry if the list is inaccurate) address the
canonicalization issue.
I agree that it seems like a reasonable approach to have two different
rpc calls (this is the Hurd analogue of file realted system calls) for
each operation taking a file name: one taking plain char names and the
other taking wide characters. Ideally, the "plain char" version should
also be passed the value of the user's LC_CTYPE, so that it can adapt.
And of course, designing new rpc-calls are only one part of the
solution. We would also need filesystems that actually implement them,
or translators that work by canonicalizing unicode names, encode them
in utf8, and then access some underlying filesystem (say, ext2).
At last the good thing is that experimenting with new rpc calls and
translators should be doable by any Hurd-hacker so inclined. It
doesn't depend on the rest of the system.
/Niels
