Re: Polished FileSystem API proposal

On Sat, Jul 13, 2013 at 2:37 AM, Kenneth Rohde Christiansen
<kenneth.christiansen@gmail.com> wrote:
> Hi there!
>
> A new file system API with a lot of "promise" :-)
>
> On Sat, Jul 13, 2013 at 2:31 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> Hi All,
>>
>> Yesterday a few of us at mozilla went through the FileSystem API
>> proposal we previously sent [1] and tightened it up.
>>
>> Executive Summary (aka TL;DR):
>> Below is the mozilla proposal for a simplified filesystem API. It
>> contains two new abstractions, a Directory object which allows
>> manipulating files and directories within it, and a FileHandle object
>> which allows holding an exclusive lock on a file while performing
>> multiple read/write operations on it.
>>
>> It's largely modeled after posix, but because we've tried to keep it
>> author friendly despite it's asynchronous nature, it differs in a few
>> cases.
>>
>> There are opportunities for further simplifications by straying
>> further from posix. It's unclear if this is desired or not.
>>
>> Detailed proposal:
>>
>> partial interface Navigator {
>>   Promise<Directory> getFilesystem(optional FilesystemParameters parameters);
>> };
>>
>> interface Directory {
>>   readonly attribute DOMString name;
>>
>>   Promise<File> createFile(DOMString path, MakeFileOptions options);
>
> Why not CreateFileOptions? the method is called createFile and not makeFile

Yup. I'll fix that.

>>   Promise<Directory> createDirectory(DOMString path);
>
> You have a data as part of the MakeFileOptions, would that be useful here?

What would it do?

>>   Promise<(File or Directory)> get(DOMString path);
>
> Then shouldn't we have a convenience to see if a path is a directly or
> not, like python has os.path.isdir(fileordirectoryname)

The get method combines the "check if exists", "check if directory",
"stat to get metadata" functions into one. We could certainly add all
three, but it doesn't seem to really make the API easier to use, just
bigger.

>>   Promise<void> move((DOMString or File or Directory) entry,
>>                      (DOMString or Directory or DestinationDict) dest);
>>   Promise<void> copy((DOMString or File or Directory) entry,
>>                      (DOMString or Directory or DestinationDict) dest);
>>   Promise<boolean> remove((DOMString or File or Directory) path,
>>                        optional DeleteMode recursive = "nonrecursive");
>
> I don't like all these weird arguments like DeleteMode etc... just
> make a separate method
>
> removeRecursively(

That's certainly an interesting idea. I'd personally prefer to just
have the recursive variant, but if we really need both then that's
probably better.

>>   Promise<FileHandle> openRead((DOMString or File) file);
>>   Promise<FileHandleWritable> openWrite((DOMString or File) file,
>>         optional CreateMode createMode = "createifneeded");
>
> Can't the user not just handle the creation in the error case of the
> promise. or create it before... It would so very easy to create a
> openWriteCreateIfNeeded method on top of the existing API. So such an
> argument should only be needed if there would be performance benefits
> - otherwise keep the API simple.

Another question is if we need openWrite with support for not creating
the file if it's not there. You could likewise easily also create a
openWriteFailIfDoesntExist on top of existing API by using the get()
function.

I don't feel particularly strongly. Create-and-open-for-writing is
probably a decently common operation. Though createFile probably
covers the most common create-and-open-for-writing scenarios.

>>   Promise<FileHandleWritable> openAppend((DOMString or File) file,
>>         optional CreateMode createMode = "createifneeded");
>>
>>   EventStream<(File or Directory)> enumerate();
>>   EventStream<File> enumerateDeep();
>
> It is not obvious for me what that method does.

It recursively enumerates all files in this directory and all
subdirectories. This is useful for things like figuring out the total
size of files under a subdirectory, or sending a full directory tree
to the server.

/ Jonas

Received on Saturday, 13 July 2013 09:58:21 UTC