On Mon, Jan 13, 2014 at 3:21 PM, Jesse <purplecabb...@gmail.com> wrote:
> Will any of the following work?
>
> <img src="cdvfile://localhost/persistent/1.png"/>
>
> xhr.open("GET","cdvfile://localhost/persistent/data.txt");
>
> <link rel="stylesheet" type="text/css"
> href="cdvfile://localhost/persistent/style.css"/>
>
If the new file plugin is installed, and the file exists, then the first
three of those should definitely work (assuming the default configuration).
>
> <a href="cdvfile://localhost/temporary/site/temp.html"
> target="_blank">Review Site</a>
>
I'm not sure about this -- haven't tried it. If it's doing navigation, then
I don't know how it plays with the fact that plugins get unloaded or reset
at some point.
The in-app-browser version of this:
window.open("cdvfile://localhost/temporary/site/temp.html", "_blank")
should work just fine.
>
>
> @purplecabbage
> risingj.com
>
>
> On Mon, Jan 13, 2014 at 10:37 AM, 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
> > >
> >
>
