HTML5 Filesystem API feedback

Hello public-webapps,

I've spent a bit of time with the filesystem API recently, building out a
set of common file dialogs (open, save-as, etc) for ChromeOS.  We have
a private API call to get access to a special filesystem that contains the
user's downloads folder and the mounted external storage, but beyond
that the dialogs use the standard filesystem API calls.

The bulk of the code is here:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/file_manager/js/

I've run into a few awkward bits that I'd like to bring up here to see what
everyone else thinks.

* The async API is really awkward when you want to resolve multiple
entries.  I have a case where I'd like to resolve a list of
directories and then do something when that completes.  It would be
helpful if the DirectoryEntry class had a getDirectories() method.
I've built my own in file_manager/js/util.js in the function called
util.getDirectories.

* That leads to a desire to get "entries" in the general sense.  In my
case I knew ahead of time that I had a list of directories.  If I
didn't know whether I had been handed directories or files, the code
would get pretty hairy.  So in addition to getDirectories, a
getEntries method (and getEntry, too) would be super useful.

* Another helper I found useful was util.forEachDirEntry from the same
file previously mentioned.  This function invokes a callback once for
each entry in a directory.  This saves the caller from having to
create the reader and walk the results array during the callback.  It
makes client code significantly more readable.  I'd love to see
DirectoryEntry.forEach(...).

* The FileError object is a bit awkward to work with.  I found that I
frequently had every reason to expect my calls to succeed (because
they were a follow-on to something that already succeeded), but I
wanted to log the failure reason in the event they didn't.  The code
online suggests a switch/case statement to turn error codes into
mnemonic strings.  This requires a hardcoded list of all known errors,
and a call out to this utility function every time you want to display
the error reason in a readable way.  I suggest adding the mnemonic
string as a property of FileError, and displaying it as part of the
toString.  (See util.getFileErrorMnemonic() and
util.installFileErrorToString() for example implementations.)


Rob.

Received on Friday, 15 April 2011 10:21:59 UTC