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 Tue, 14 Jan 2014 15:38:02 GMT
On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve <agrieve@chromium.org> wrote:

> I think we need two things for transitioning to different PERSISTENT /
> TEMPORARY locations:
> 1. The ability for the user to retrieve the files at the old location
> (so they can be moved to the new location)
> 2. The ability to turn turn on the change with a switch (e.g.
> <preference name="IosUseLegacyFileSystemPath" value="true" />)
>
> I'd love for the default to be the new locations so that new apps
> don't forget to turn on the preference and find out they need to
> migrate later on.
>

This is the really dangerous bit, though. If we make the default anything
but the current behaviour, then devs *will* update their plugins and push,
and users *will* lose the ability to access old saved files. We will
absolutely encounter the situation where developers test their app with
blank filesystems, and everything works fine, but data is rendered
inaccessible to users who upgrade from an old version. And I'm sure it'll
happen no matter how loudly we announce the change.

I would sooner make the new plugin be "broken by default", so that the app
doesn't even start until you add a configuration preference, one way or the
other. Then we could recommend at that time, "if you have an existing app
with users, then use the old value; if this is a brand new app, use the new
one".

Also - the simpler our instructions can be, the better. I don't think
> most devs even realize that they are doing a foolish thing with the
> way things are set up right now, so telling them to configure their
> own paths might put too much of a burden on them (they'd have to learn
> where files should go, and then also figure out how our config syntax
> works).
>

True. The simple case should be as simple as possible. Ideally, doing
nothing at all should get them some reasonable behaviour, compatible with
previous versions.


>
> The case of adding new FS roots is compelling, but I think most users
> would appreciate FS roots for content, assets, sdcard, etc to be
> pre-built-in rather than have to wire them up themselves.
>

Agreed. Those ones should be available out-of-the-box, either as part of
File, or as part of a related plugin. (Leaning towards File, since it is
already providing content and assets filesystem URLs)



> One thing that jumped out to me is the src= argument:
> <filesystem name="documents"
>     type="local-filesystem"
>     prefix="cdvfile://localhost/documents"
>     src="Documents" />
>
> If the goal is for these to be customizable, then it's not that
> flexible to use pre-defined values in the src= argument. Perhaps
> instead of using config.xml, the File plugin could have a
> registerFileSystemRoot(name, type, prefix, rootPath) function that
> could be used for this purpose. That way plugins could compute their
> root paths and then call this function at plugin init time.
>

That was mostly an off-the-top-of-my-head strawman for the format. However,
it does address the issue of how to specify "this filesystem lives at the
NSTemporaryDirectory location; that one lives at NSLibraryDirectory",
without having to know the real filesystem path for those things.

I expected that the interpretation of something like a "src" attribute
would be very dependent on the filesystem type, and specialized to that
type, rather than representing an absolute device fs path.


>
>
>
> Another thing that occurred to me (maybe off topic?): Why:
> cdvfile://localhost/documents
> instead of:
> cdvfile://documents/
> Looking at this URL-wise, I think it would be a nice-to-have to have
> the type encoded as the hostname so that root-relative URLs would work
> with the URLS.
>

We discussed this at the Waterloo meetup, and there was definitely some
push for having the authority part in the URL be the real authority
(localhost), for consistent URL handling.

Having the FS type be the authority would make some of the internal URL
parsing easier, but I don't know if it causes problems anywhere else.


>
>
> Could we get away with just two parameters to each FS root?
> 1. Name (use this to determine prefix as cdvfile://${name})
> 2. src (URI to be considered the root of the FS).
>

Those are, internally, the parameters used by the "local filesystem" FS
type (i.e., not "content" or "assets library".) The actual device-FS root,
though, is currently determined at run time by the device, based on whether
it is the temporary or persistent FS.


>
>
>
>
> On Mon, Jan 13, 2014 at 4:29 PM, Ian Clelland <iclelland@chromium.org>
> wrote:
> > On Mon, Jan 13, 2014 at 3:21 PM, Jesse <purplecabbage@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 <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