Pete is right, partly. It has been suggested that we split the API into
a file system service interface and a file specification instance
interface. I am unsure of the gain. comments?
The main issue is what kind of strings does the nsIFile take. I never
understood the rationale behind adding wstring/unicode accessors on the
nsIFile in addition to the char* methods. Why can't we just use utf8?!
Jag or Scc would be the people in the know about what string to use in
this base interface. I think Jag is suggesting nsAString?
Here are the requirements:
1. Users must be able to use |const char*|'s to initialize nsIFile.
(ease of use).
I want:
NS_NewLocalFile(const char* path, PRBool followLinks, nsILocalFile* *result);
to still work.
2. nsIFile is used before xpcom is initialized - we must ensure that
underlying services are not to create a nsIFile. I guess the string
classes are build under xpcom so this is not a problem - but using the
internationalization stuff may be. To rephrase - we must be able to
create a nsIFile without starting any additional services!
See:
http://lxr.mozilla.org/seamonkey/source/xpcom/build/nsXPComInit.cpp#255
3. One entrypoint for every verb - no Append & AppendWide.
The next issue: spawn should go away. Yes. There is already an
nsIProcess which has deprecated nsIFile::Spawn. This should be removed
the next time anyone touches nsIFile & callers.
If someone is going to take on this work, now is a good time to remove:
nsFileSpec, nsFileURL, nsFilePath, and related file spec cruft. It
should not be too difficult since most of the callers have converted.
Those that have not converted are: cookies, wallet, plugins, rdf, and
profile. These should be trivial to convert.
--
Doug Turner
[EMAIL PROTECTED]
