cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <>
Subject Transitioning to a better File API implementation
Date Fri, 15 Nov 2013 14:29:44 GMT
After working with the File plugin for a week or so, I've gotten it more or
less where I want it to be on iOS, and am working through Android. Looking
at the end result, though, I expect that over 90% of the code has been
touched in some way. (It's a huge diff.) I'd rather not simply dump this in
to the repo as a monolithic change, so I'm planing on splitting it up into
smaller, sensible steps.

I think we can transition from one to the other by doing this:

1. Harden the tests

Many of the tests in the test suite are fragile, and depend on
implementation-dependent things like whether root directory paths end with
a "/" or not, or whether a particular URL scheme is valid. I'm first going
to fix those tests which don't pass under both the old and new systems.

2. Update the JS code to allow the FileSystem object to format paths used
in exec() calls.

Since CB-5129, all Entry objects should have a filesystem object attached.
By allowing this FS object to determine what information goes across the
bridge, we are 90% of the way to using URLs internally, rather than (real)
filesystem paths, which was one of the goals of the refactoring.

3. Switch native code to use filesystem://localhost/* URLs internally, and
change the FileSystem JS object to use those URLs for the bridge.

(This gets us the rest of the way.) We can do this one platform at a time,
as well, by providing platform-specific JS code for FileSystem.

4. Add URL handlers for filesystem:// URLs in native code

This last step lets us close CB-5007, by intercepting network requests for
filesystem://* and returning the correct data. At this point, we can
actually use the results returned by FileEntry.toURL() as the source for
images, script tags, etc. Like step #3, this is opt-in, for platforms which
can support it. Platforms that don't can just continue to have their
FileSystem objects product URLs which *can* be accessed from the webview.

One final step, which can be done as part of #3, or afterwards, is to
modularize the code so that additional filesystems can be added. For iOS,
this means Asset-Library URLs, which no longer have to be special-cased in
every API call. Future filesystems can provide synced storage, or media
gallery access, or encrypted storage, or anything else we dream up.


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