I'm trying to understand: precisely what does this provide us that requestFileSystem does not? (Currently.)
Another thing to consider, we need to document the differences from the W3C proposed standards and get that feedback back to the browser vendors. On Tue, Nov 5, 2013 at 4:35 PM, Ian Clelland <[email protected]> wrote: > 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? >
