cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Configuring the File plugin
Date Mon, 13 Jan 2014 15:32:58 GMT
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