In addition to what's been discussed here, two more things.
1) We need a way to get a relative path for storing in prefs and the
profile registry. The path returned by
nsILocalFile::GetPersistentDescriptor() is, on Windows & Linux, a full
path. On the Mac, it's an encoded file alias so it doesn't have this
problem. Writing absolute file paths into the prefs (mailnews does a lot
of this) means that you can never move your profile dir, rename your
home directory, and it presents a big problem for plans of profile roaming.
Something I posted to n.p.m.xpcom about this:
All we need to do this is to have a file descriptor which is not an
absolute path, but a relative path. The point to which it's relative
would be any location defined by nsIDirectoryService. What we could do
is to add methods to nsILocalFile:
void getRelativeDescriptor(in string fromLocation, out string desc);
Here, fromLocation is a key defined by directory service. What comes out
in desc is a string with the key and then a UTF-8 encoded relative path.
The relative path is made from the location returned by directory
service for fromLocation. If a relative path can't be made (the file is
on a different drive from fromLocation), it's an error. The desc can be
stored in a registry, prefs, and so on.
void initWithRelativeDescriptor(in string desc);
Here, a file will take the desc string, decode it, and initialize itself
with it. The way the relative path is written the same on all platforms,
using whatever format we decide. The implementation of nsILocalFile on
each platform will have to convert this generic relative path into a
native relative path.
**************************
2) We need to use Unicode internally to specify files and having the
nsIFile API take only wide strings would enforce this. Using our own
i18n code to map between Unicode and the file system charset is wrong.
1) It has to determine the file system charset and map between that and
Unicode. On the Mac, it's possible to have a US system (the file system
char set is MacRoman) and then a Japanese language pack installed and
set as the system script. Which charset is chosen as the file system
charset?
2) If the system was booted in one script, a file was made, then the
system rebooted in another script, our i18n conversion may again do the
wrong thing.
On file systems which deal in Unicode, we should let the OS handle this
and both of the above problems would not occur. On file systems which
don't deal in Unicode, hmm. Just convert the unicode name to utf-8 and
pass that to the file system? The important thing is to not do the
conversion ourselves. This also cuts the dependency on i18n services
which has been given as a downside of a Unicode-only nsIFile.
-Conrad
