I think it is acceptable to have the desktopDirectory, and userDirectory point to the same dir as documentsDirectory on devices that do not support un-sandboxed file locations.
On Android, this would mean desktop, user, documents all equal : /mnt/sdcard And on iOS : /var/mobile/Applications/uid/Documents Having these there is more just for when we incorporate more desktop environments, ie Win32 and/or Mac. I am fine with removing them, however, we have to be mindful that there are potentially many more file locations. For example, WinRT ( Windows8.1 + WP8.1 ) support the downloads folder, as well as 'known' folders [1] [2] [1] http://msdn.microsoft.com/en-ca/library/windows/apps/windows.storage.knownfolders.aspx [2] http://msdn.microsoft.com/en-ca/library/windows/apps/windows.storage.downloadsfolder.aspx @purplecabbage risingj.com On Tue, May 13, 2014 at 1:57 PM, Andrew Grieve <agri...@chromium.org> wrote: > Thanks Jesse, > > Less async is definitely nicer. > > Providing URLs vs DirectoryEntry I don't think is a huge difference either, > so fine with that (although it means you need to do an async call on the > URL to get a DirectoryEntry in order to create a file). Often though, you > just use the URLs with Camera FileTransfer, so there are some cases where > it's nice. > > Don't think desktopDirectory or userDirectory make sense since apps are > sandboxed these days. > > Will take a stab at a commit and report back via pull request. > > > > On Tue, May 13, 2014 at 4:37 PM, Jesse <purplecabb...@gmail.com> wrote: > > > Okay, here goes. > > > > Re: > > > > > > cordova.plugins.file.getDirectoryForPurpose(purpose, options, win, fail) > > Where purpose can be one of: > > var Purpose = { > > 'data': 0, // General application data (default) > > 'documents': 1, // Files that are meaningful to other applciations > > (e.g. Office files) > > 'cache': 2, // Temporary files that should survive app restarts > > 'temp': 3, // Files that can should be deleted on app restarts > > 'app-bundle': 4 // The application bundle (iOS only) > > } > > // And the aliases > > cordova.plugins.file.getDataDirectory(syncable, win) > > cordova.plugins.file.getDocumentsDirectory(win) > > cordova.plugins.file.getTempDirectory(win) > > cordova.plugins.file.getCacheDirectory(win) > > > > > > Ultimately these will never change while the app running, why not just > have > > them be properties that are populated on startup? > > Also, given that they won't change, the async alias calls would not > > required. > > > > My suggestion is based in part on the Adobe Air File class which solves > > many of the same problems[1] > > > > I would rather see an API that looked like : > > > > // a storage directory unique to each installed application > > File.applicationStorageDirectory; > > // the read-only directory where the application is installed (along with > > any installed assets) > > File.applicationDirectory; > > // the user's desktop directory, not available on all devices > > File.desktopDirectory; > > // the user's documents directory, not available on all devices > > File.documentsDirectory; > > // Cached files that should survive app restarts > > File.cacheDirectory; > > > > // temp will only live for the lifetime of the app, so if you want a ref, > > you will have to keep it. > > // note also that you can create several temp directories if you want. > > var tempDir; > > File.createTempDirectory(function onSuccess(dirResult){ > > tempDir = dirResult; > > },function onError(errResult){ > > tempDir = null; > > console.log("Error creating temp directory :" + > > JSON.stringify(errResult)); > > }); > > > > As an altenative, a root temp dir could be created when the app launches, > > making this async call unnecessary, and then these could be referenced > just > > like the other dirs > > That would make this just : > > > > // location unknown, and volatile > > File.tempDirectory; > > > > > > [1] > > > > > http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/filesystem/File.html > > > > > > > > @purplecabbage > > risingj.com > > > > > > On Tue, May 13, 2014 at 9:02 AM, purplecabbage <purplecabb...@gmail.com > > >wrote: > > > > > Yeah almost. Still brewing a little. > > > Give me a couple hours. > > > > > > > > > > > > > On May 12, 2014, at 10:05 AM, Andrew Grieve <agri...@chromium.org> > > > wrote: > > > > > > > > Now that email works again - Jesse, were you thinking of proposing a > > > tweaks > > > > API, or something different altogether. > > > > New related bug here: > > > > > > > > https://issues.apache.org/jira/browse/CB-6670 > > > > > > > > > > > >> On Tue, May 6, 2014 at 6:21 PM, Brian LeRoux <b...@brian.io> wrote: > > > >> > > > >> That is a very good point! I say it is good enough for now. > Something > > to > > > >> flag for our W3C friends to look at and consider in the spec. > > > >> > > > >> > > > >> On Tue, May 6, 2014 at 1:43 PM, Andrew Grieve <agri...@chromium.org > > > > > >> wrote: > > > >> > > > >>> There are two types of config for file: > > > >>> 1. You can do is disable parts of the filesystem (doubt anyone > would > > do > > > >>> this) > > > >>> 2. You can switch where PERSISTENT filesystem maps to (sane place > vs > > > >> legacy > > > >>> place) > > > >>> > > > >>> What's missing is a way to retrieve the paths that you might want. > No > > > >>> configuration required for this part. > > > >>> > > > >>> I'd like to avoid making the calls look like they are a part of the > > > file > > > >>> spec, so that users won't be tempted to think that it would work > in a > > > >>> non-Cordova environment. > > > >>> > > > >>> > > > >>>> On Tue, May 6, 2014 at 1:47 PM, Brian LeRoux <b...@brian.io> wrote: > > > >>>> > > > >>>> This plugin is helpful though I can't help but wonder if we can't > > > >>> shoehorn > > > >>>> into specs (or at least provide spec feedback). > > > >>>> > > > >>>> Right now all config is done w/ config.xml instead of programmatic > > (?) > > > >>>> > > > >>>> > > > >>>> On Tue, May 6, 2014 at 7:06 AM, Andrew Grieve < > agri...@chromium.org > > > > > > >>>> wrote: > > > >>>> > > > >>>>> Closer than ever to resolving this (woo!) > > > >>>>> > > > >>>>> The file plugin is now able to read & write to roots on the > > > >> filesystem > > > >>>>> beyond PERSISTENT and TEMPORARY on iOS, Android, and BlackBerry > > (and > > > >>>> maybe > > > >>>>> others?) > > > >>>>> > > > >>>>> However, you still can't query for the location of these places > > > >> (doh!) > > > >>>>> > > > >>>>> There's a file-extras plugin in cordova-labs: > > > >> > > > > > > https://git-wip-us.apache.org/repos/asf?p=cordova-labs.git;a=blob;f=file-extras/fileextras.js;h=1f8f88f7222bd4022f2f802f6825c189b10445d9;hb=aaf61d4 > > > >>>>> > > > >>>>> That was used to experiment with an API for this. I think the API > > is > > > >>>> pretty > > > >>>>> much fine, and I'd like to add it to the core file plugin rather > > than > > > >>>> have > > > >>>>> it as a separate plugin. > > > >>>>> > > > >>>>> This would add: > > > >>>>> cordova.plugins.file.getDirectoryForPurpose(purpose, options, > win, > > > >>> fail) > > > >>>>> > > > >>>>> Where purpose can be one of: > > > >>>>> var Purpose = { > > > >>>>> 'data': 0, // General application data (default) > > > >>>>> 'documents': 1, // Files that are meaningful to other > > > >> applciations > > > >>>>> (e.g. Office files) > > > >>>>> 'cache': 2, // Temporary files that should survive app > restarts > > > >>>>> 'temp': 3, // Files that can should be deleted on app > restarts > > > >>>>> 'app-bundle': 4 // The application bundle (iOS only) > > > >>>>> } > > > >>>>> > > > >>>>> And also add convenience wrappers: > > > >>>>> cordova.plugins.file.getDataDirectory(syncable, win) > > > >>>>> cordova.plugins.file.getDocumentsDirectory(win) > > > >>>>> cordova.plugins.file.getTempDirectory(win) > > > >>>>> cordova.plugins.file.getCacheDirectory(win) > > > >>>>> > > > >>>>> > > > >>>>> Any comments on this? > > > >> > > > > > >
