Doug Turner wrote:
> 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
>
Given that some of the things which are done only on local, disk based files
(hence the reason for nsILocalFile in addition to nsIFile) have been moved
into the File System service, what's left in nsILocalFile becomes so small.
Do we still need the distinction between the two?
>
> 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.
That would be good since append() only handles one node at a time.
I would keep it that way as appendRelativePath() takes a native path
with possibly multiple nodes. I think we should limit the use of native
paths as much as possible.
>
>
> 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
