I am apprehensive about making this surface configurable. (I can live w/ our own protocol cdvfile:// personally).
The main use case is being able to add custom storage providers in the future? (Might be good to add this to the 'lets talk configuration' backlog / meeting.) On Mon, Jan 13, 2014 at 7:32 AM, Ian Clelland <iclell...@chromium.org>wrote: > 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 >
