The new File plugin is essentially ready, for iOS and Android (with, hopefully, no breaking changes for those or other platforms)
I had to move away from the "filesystem://" URL scheme -- on Android 4.4, that scheme appears to be special, and doesn't defer to WebView.shouldInterceptRequest(). (I filed https://code.google.com/p/chromium/issues/detail?id=333395 on Friday once I had isolated the problem.) For now, I've settled on "cdvfile://", but the issue is open to bikeshedding, I suppose. What I'd really like to open for discussion though, is the idea of making the whole plugin configuration, er, configurable. The URL scheme is one driving force behind this; the historical locations of the TEMPORARY and PERSISTENT filesystems is another; the new ability to open up completely new filesystems is a third. I'm thinking of implementing a section in config.xml that would define the names of the installed filesystems available to a Cordova app, along with their type, the URL prefix to use, and any other required details (like *where the files live*). Something like this: <widget> <filesystems platform="android"> <filesystem name="temporary" type="local-filesystem" prefix="cdvfile://localhost/temporary" src="cache" /> <filesystem name="persistent" type="local-filesystem" prefix="cdvfile://localhost/persistent" src="Documents" /> <filesystem name="content" type="content-filesystem" prefix="content://" /> </filesystems> </widget> or <widget> <feature name="File"> <filesystems platform="android"> <filesystem name="temporary" type="local-filesystem" prefix="cdvfile://localhost/temporary" src="cache" /> <filesystem name="persistent" type="local-filesystem" prefix="cdvfile://localhost/persistent" src="Documents" /> <filesystem name="content" type="content-filesystem" prefix="content://" /> </filesystems> </feature> </widget> (The platform's defaults.xml, or whatever we're calling it these days, could specify the default mapping, so that devs could write cross-platform apps without having to add this for every platform, or even at all, if they don't care to change it) I think that being this explicit will let us change the url scheme as needed (hopefully cdvfile won't need to change, but it would have if it was still "filesystem"). It could eventually allow new FS plugins to be added to an app with this mechanism. And it would mean that we could roll out a default configuration that left the iOS files in their current locations: <filesystem name="temporary" type="local-filesystem" prefix="cdvfile://localhost/temporary" src="Temporary" /> <filesystem name="persistent" type="local-filesystem" prefix="cdvfile://localhost/persistent" src="Documents" /> and then, in a later version, we could change the default for new projects to <filesystem name="temporary" type="local-filesystem" prefix="cdvfile://localhost/temporary" src="Temporary" /> <filesystem name="persistent" type="local-filesystem" prefix="cdvfile://localhost/persistent" src="Library" /> <filesystem name="documents" type="local-filesystem" prefix="cdvfile://localhost/documents" src="Documents" /> and existing projects shouldn't see any change. And in the meantime, any dev who wanted to use the more sensible filesystem locations could just change their own config.xml. I'm going to take a stab at implementing this as described, but discussion is certainly welcome before it goes out to the world. As multiple people have said, we need to get this right, and not hurt all of our existing devs. Ian
