Re: HTML5 Filesystem API feedback

Robert:

First of all, thanks for the feedback.

On Wed, Apr 13, 2011 at 1:35 PM, Robert Ginda <rginda@chromium.org> wrote:
> 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.

In general, I'm pretty happy to see this sort of thing.  You may not
like to hear this, but any problem that can just be solved by layering
a small javascript library on top of this API is a problem we don't
need to fix in the first pass of the API.  We want it to start out
powerful and simple, and eventually, if that library is something that
absolutely everyone seems to need, we may want to incorporate it.  So
it is very helpful to see the kinds of libraries that get built on
top, and thanks for sending the pointer, but I suggest we wait and see
before making any changes.

BTW, you can make your getDirectories method faster if you don't wait
for a response before sending off the next query [assuming no memory
constraints].  Just fire off all the requests in one go, then keep a
countdown of responses in your callback-wrapper.  When your countdown
hits zero, fire the "we're done" signal.

> * 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.

This is a method that would look up, but not create, an Entry, given a
path?  Can you outline the circumstances in which you'd use this, but
where you wouldn't want to list the whole parent directory?

> * 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(...).

I can see the utility there pretty clearly.

> * 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.)

Hmm...I'm not sure what other APIs usually do about this.  As soon as
you start adding strings that you intend to be human-readable, you
start getting into all sorts of internationalization issues.  Anyone?

	Eric

Received on Friday, 15 April 2011 18:54:09 UTC