cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Configuring the File plugin
Date Mon, 13 Jan 2014 18:37:42 GMT
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 <iclelland@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
>

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