cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Proposed changes to Cordova File API
Date Tue, 05 Nov 2013 16:18:53 GMT
So, coming out of our meetup last week, we brainstormed a bunch of ideas
for improving the Cordova File plugin. I'm going to start working on these,
but I want to share with the list so that everybody knows what's going on,
and so we can have any additional discussions :)

I think that we had general agreement on these points, but let's talk:

1. Entry.toURL() should return a filesystem:// URL on platforms which
support it. Platforms which cannot support custom URL protocols are free to
return URLs which *can* be used to access the local file system.

2. These URLs will look like:

  filesystem://localhost/persistent/path/to/file.ext
  filesystem://localhost/temporary/path/to/file.ext

Additional roots are possible for new file systems (assets, media,
documents, etc)

(The specific format used does not need to conform to any existing or
proposed standard, since these URLs should not be assumed valid across
machines)

3. Entry.fullFath will be relative to the HTML file system root, and not a
path from the root of the actual device file system.

4. Only URLs will be passed over the exec bridge; we won't be passing raw
file system paths into and out of JS anymore. (This generally means
filesystem:// URLs in the iOS/Android case, but platforms are free to
support other URLs as needed)

5. At some point (not right now) we should move the permanent storage
location on iOS from <app-root>/Documents to <app-root>/Library, so that
the entire HTML5 file system doesn't get exposed in iTunes, synced with
iCloud, etc. This will almost certainly require a major version change and
a migration plan for existing apps, so I'd like to separate that work from
the first four points.

We also discussed shipping a new API with Cordova, get*Directory(), which
is currently in the File-extras plugin. After some thinking, I think it's
not really required, but I'm open to talking about it. I'll start another
thread for it.

Ian

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