> Factoring nsIFile into two pieces.
Sounds like a plan. Why? Better Organization?
> Removing non unicode functions.
So we initialize the local file object with `initWithUnicodePath'
instead right?
Is there any bad things you can think of for the scripting side of
things other than API changes?
Some things i think nsIFile needs:
1. a way to unlink symlinks
2. a recursive copy
3. chown
4. chmod
Remember, these `unistd' and `stat' lib calls will soon be relevant on
the mac ;-)
--pete
> 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
