On Thu, Nov 7, 2013 at 4:47 AM, Brian LeRoux <[email protected]> wrote: > 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) >
I think so, or at the very least guidance. I'm not sure that we need to bundle this with plugins, but we could have a repository of helpful code snippets either in cordova-labs or just in blog posts. I thought that requestFileSystem + hints would help devs be browser portable, but I think Andrew&Brian are right that we should instead be clear that this is a cordova extension, and instead provide guidance on how to make a browser shim for the cordova extension (or just make our extensions super obvious how to be shimmed in browser, as I think this one would be). > > > 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? > > > > > > > > > > > > > > > > > > > > >
