cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: CB-285 (FileSystem paths)
Date Tue, 13 May 2014 22:32:06 GMT
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 <agrieve@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 <purplecabbage@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 <purplecabbage@gmail.com
> > >wrote:
> >
> > > Yeah almost. Still brewing a little.
> > > Give me a couple hours.
> > >
> > >
> > >
> > > > On May 12, 2014, at 10:05 AM, Andrew Grieve <agrieve@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 <agrieve@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 <
> agrieve@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?
> > > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message