On Tue, Nov 5, 2013 at 9:32 AM, Brian LeRoux <[email protected]> wrote: > I'm trying to understand: precisely what does this provide us that > requestFileSystem does not? (Currently.) >
I think it currently provides two things, of dubious value: First, it's a synchronous API, so if you need to get a URL to store a document, you could just write: var docsURL = getDocumentsDirectory(); and you immediately have a file:/// url that you can use with any of the URL-based APIs (like FileTransfer) to save documents. Whether the synchronous API is valuable or not is up for debate :) At the least, it lets you set that up early in your application, without having to wrap the whole app in a callback, or go through hoops with asynchronously testing and setting global variables. Second, and probably more important right now, is that it's currently developed independently of requestFileSystem. Currently, we have getCacheDirectory, getDocumentsDirectory, getTempDirectory, and getDataDirectory, but there is no corresponding 'cache' or 'documents' file system. They just return paths like "/var/mobile/some-long-uuid/appname.app/Documents/" This has let us deal with the idiosyncrasies of the various platforms -- their media storage, document storage, etc -- without having to write all of the code to handle that through the File API. But I think that I'm going to be doing the bulk of that work anyway. I don't think this will be necessary after we're finished overhauling the FIle plugin; it will be much easier to just add new file system roots for each of these things. > Another thing to consider, we need to document the differences from the W3C > proposed standards and get that feedback back to the browser vendors. > Yep; if there is a legitimate case for these functions -- the sync api, or the URL-centric API (as opposed to the FileEntry-centric API), then we should definitely be letting the standards folks and the browser vendors know. Ian > > > 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? > > >
