At today's API review, we took a look at nsIFile and friends. The
conclusion was some serious changes to this interface which will effect
all callers. By some napkin calculations, we estimated at least 3 weeks
of work for this complete task. I will present what was proposed.
In Generally, the changes are:
Factoring nsIFile into two pieces.
Removing non unicode functions.
Removing explict symlink function.
These changes are all independant of one another, but probably should be
done serial by one person.
The biggest change is that nsIFile and nsILocalFile should be split into
two logical pieces: file description and the file system service. The
first piece would just be basic filepath manipulation, initalization,
and stat getters. The other piece, the file system service (I pull that
name out of the air) would take one or two nsIFile's and perform
operations on them.
So, copying and pasting things around, the nsIFile would have the
following members/attributes:
void append(in wstring node);
attribute wstring leafName;
attribute unsigned long permissions;
attribute wstring URL;
attribute string persistentDescriptor;
attribute PRInt64 lastModificationDate;
attribute PRInt64 fileSize;
readonly attribute wstring target;
readonly attribute wstring path;
void normalize();
boolean exists();
boolean isWritable();
boolean isReadable();
boolean isExecutable();
boolean isHidden();
boolean isDirectory();
boolean isFile();
boolean isSymlink();
boolean isSpecial();
attribute PRBool followLinks;
The new File System service would have the follow operands:
create
createUnique
copyTo
moveTo
delete
clone
equal
contains
getParent
getDirectoryEntries
openNSPRFileDesc
openANSIFileDesc
load
diskSpaceAvailable
The parameters of the above functions in the file system service would
include an extra nsIFile which use to be the "this". As an example, the
method |load| will now contain one in param which is the nsIFile which
should be loaded.
There were two addition changes to these methods above which were
discussed:
The first additional comment is that we should remove the non unicode
version of all methods. I believe that i18n will be happy with this.
However, I am not sure how this will effect most users. Looking over
the codebase, most places we are dealing with unicode anyways, however,
there may be places which will have to convert from ansi to unicode.
The second additional change is that the followSymlink attribute will
apply to the terminal node during appending (which may include
initialization of the nsIFile), as well as any of the FileSystem
functions. This allows us to compress/remove all of the
"followingSymlink" functions. So, supposing you have a nsIFile of a
directory, and you wanted to copy it somewhere while resovling the
symlink, you could simply set the followingSymlinks flag to true, then
call into the FileSystem service. Another example, is if got a nsIFile
from the directory service and you wanted to append a relative path
which may contain a symlink, you would again set this flag to true, then
call |append|. Unlike the current interfaces, if you set the flag back
to false, your working path will still be valid.
Another change which I am proposing which I didn't in the meeting is to
remove AppendRelativePath. The simple method |append| should just
handle this case.
Here are Jud's Notes:
nsIFile -
http://www.mozilla.org/projects/embedding/apiReviewNotes.html#nsIFile
nsILocalFile -
http://www.mozilla.org/projects/embedding/apiReviewNotes.html#nsILocalFile
Thanks,
Doug Turner
