cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject New filesystem roots API?
Date Tue, 05 Nov 2013 16:35:06 GMT
During our FIleSystem API brainstorming session, we visited the idea of
having an API to obtain URLs to various file system roots with a
synchronous call. I was a big fan at the time, but I'm no longer certain
that it provides any advantages over window.requestFilesystem.

(Most of this code currently lives in the File-extras plugin, but the idea
would be to promote this to the File plugin, I believe.)

The API would consist of a set of JS functions, get*URL (currently
get*Directory) -- getTemporaryURL, getMediaURL, getDocumentsURL, etc. These
would return a URL which could then be used directly as a root for the
files stored in it, or passed to window.resolveLocalFilesystemURL to
retrieve a DirectoryEntry object.

On systems which support filesystem:// URLs, this would probably return
things like filesystem://localhost/temporary/,
filesystem://localhost/documents/, etc.

On systems which cannot support custom URLs -- BB10, maybe Windows Phone?
-- this could return usable URLs like local:///path/to/documents/, or
file:///path/to/documents/

This API is essentially a counterpart to window.requestFileSystem, and I
think that it could be implemented in an asynchronous fashion essentially
like this:

getDocumentsDirectory = function(callback) {
    window.requestFileSystem('documents', function(fs)) {
      callback(fs.root.toURL());
    });
});

Questions:

Is there a pressing need for a synchronous version of this, or is the async
version above enough?
Do we believe that other situations will arise where fs.root.toURL will
return a different value than the corresponding get*URL function?
I think it is better to support new FS roots by adding new HTML filesystems
to window.requestFileSystem, rather than just defining new URLs which
aren't accessable any other way. Am I right in this, or are there going to
be significant hurdles to adding new roots for things like 'media',
'documents', 'cache', etc?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message