+1 to configurable The main reason would be to make changing (default) locations easier. As described the upgrade to move to new (more sensible) locations is easy to manage and supports people with legacy apps that don't want to change.
On Mon, Jan 13, 2014 at 1:37 PM, Brian LeRoux <b...@brian.io> wrote: > 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 > > >
