I tend to agree. Keeping this as a standalone extension will give us a clear 'thing' to allow devs to shim out if they want to be browser compatible. Also, in favor in async.
Brings up a deeper philosphical discussion: should we be providing shims for functionality so that our community user land code is browser portable? (Eg, noop's or console logs in development) On Thu, Nov 7, 2013 at 9:11 AM, Andrew Grieve <[email protected]> wrote: > -1 to using requestLocalFileSystem. RLFS is a standard, and what we're > adding here is not a part of it. I think there is value in keeping > Cordova-specific logic separate so that it's easy for devs to know when > they are using an API that is Cordova-specific (as opposed to a polyfill). > That said, I think resolveLocalFileSystemURL() should be extended to allow > creating an Entry for these custom URLs. > > +1 async API since some platforms will need to use exec() to implement. > > > > > > On Wed, Nov 6, 2013 at 2:30 PM, Michal Mocny <[email protected]> wrote: > > > I think perhaps the motivation here is being lost in the sea of details. > > Let me attempt to decompose the motivation into very few words (please > > correct me Ian): > > > > * We desire a way for apps to access to "the idiosyncrasies of the > various > > platforms -- their media storage, document storage, etc" > > * window.requestFileSystem (currently) cannot do this, but we could > extend > > it by adding new FS types. This would naturally be async. > > * We also want a way to resolve those locations to filesystem:// paths > (or > > equivalent) for use with FileTransfer etc. > > * ..a plugin was recently added to cordova-labs to implement one way of > > accomplishing this, but Ian is suggesting its the wrong way. > > > > > > My answer: > > > > +1 to adding hints to window.requestFileSystem. (But I'm not 100% on how > > best to extend the API, though. I kinda like adding a new "hint" > parameter > > instead of replacing the FS type, which could perhaps be ignored on > > platforms that don't support it and simply fallback to PERSISTENT?) > > > > async only is fine, but maybe its trivial to add the sync getters > > (window.requestFileSystemPath() or something)? > > > > Either way, it would be very easy to write a userland library that > > implements a single async init() that caches the paths and provides sync > > getters from that point onwards, so app devs don't have to figure that > out > > themselves. > > > > -Michal > > > > On Tue, Nov 5, 2013 at 2:10 PM, Ian Clelland <[email protected]> > > wrote: > > > > > 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? > > > > > > > > > > > > > > >
