cordova-dev mailing list archives

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

Two big use cases, for me:

First is being able to change the location in which files are stored: On
iOS, for instance, we store the Persistent filesystem in the Documents
directory, which makes every file created by the application visible to the
user in iTunes, where that directory is supposed to be used for large,
document-style artifacts, and not for collections of small
application-internal files. iOS has a Library directory for that sort of
thing, and those files can stay internal to the application. I'd like to
switch to that Library directory, but that's a very very breaking change
unless we make it configurable like this.

Second is the ability to add custom storage providers, as separate plugins.
That will require some more machinery in the File plugin, but a config like
this is a first step towards it.


> (Might be good to add this to the 'lets talk configuration' backlog /
> meeting.)
>

If we haven't hashed it out on the list by then, we should definitely use
that meeting to work some of this out.


>
>
> 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