On Tue, Jan 14, 2014 at 2:52 PM, Brian LeRoux <b...@brian.io> wrote:
> Wait, users lose data IF they upgrade the plugin. Is that correct?
>
*If* we change the default storage location, and *if* a developer upgrades
the file plugin without looking too closely (because, hey, newer is always
better, right?) and pushes a new version of the app to existing users, then
yes, users will lose access to the data that they previously had stored.
Technically, they aren't losing the data; it's still possible to get to it,
someday, maybe, if the developer does a lot of work to fix the app, and it
hasn't ended up in some inconsistent state -- it's not deleted, though.
And I do believe that developers will do that, too. Maybe not the good ones
:) But people will gloss over the upgrade instructions, read the warnings
without thinking "oh, that affects my users", and publish away.
>
>
> On Tue, Jan 14, 2014 at 10:53 AM, Ian Clelland <iclell...@chromium.org
> >wrote:
>
> > On Tue, Jan 14, 2014 at 1:44 PM, Brian LeRoux <b...@brian.io> wrote:
> >
> > > So, to be clear and terse: what are the use cases / why are we adding
> > more
> > > config?
> > >
> >
> > 1. NSDocumentsDirectory is a stupid place to put the HTML filesystem on
> > iOS. NSLibraryDirectory is a more sensible place, and I'd love to change
> it
> > as part of this rollout, *but*
> > 2. If we change it unilaterally, real users are going to lose access to
> > real data.
> >
> > Also,
> > 3. The File plugin is much more modular now, and we could potentially
> have
> > a whole ecosystem of Filesystem providers making filesystem-shaped
> things,
> > but it needs to be configurable to be useful.
> >
> > #3 is less important at the moment, but becomes more compelling if we
> > provide the machinery for other devs to take advantage of it.
> >
> >
> >
> > >
> > > On Tue, Jan 14, 2014 at 10:34 AM, Ian Clelland <iclell...@chromium.org
> > > >wrote:
> > >
> > > > On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve <
> agri...@chromium.org
> > > > >wrote:
> > > >
> > > > > On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland <
> > iclell...@chromium.org
> > > >
> > > > > wrote:
> > > > > > On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve <
> > agri...@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".
> > > > >
> > > > > I really like this idea!
> > > > >
> > > > > >
> > > > > > 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.
> > > > >
> > > > > If the valid values here are pre-determined by the FS type, then I
> > > > > don't know why we'd have this configuration.
> > > > > Let's just expose all of the roots that the FS knows about. If we
> > want
> > > > > to be able to toggle some on/off, then let's add a pref for
> > > > > "fs-type-whitelist" which is just a comma-separated-list.
> > > > >
> > > > >
> > > >
> > > > A comma-separated list isn't so bad; in fact, given the call
> signature
> > of
> > > > requestFileSystem, the *order* of items in that list may be the
> > critical
> > > > thing. A CSL is certainly easier to shoehorn into our existing config
> > > > parsing than a whole block of XML, even if it's a bit uglier.
> > > >
> > > > What about something shaped like
> > > >
> > > > <preference name="filesystems"
> > value="temporary,documents,assets,library"
> > > > />
> > > >
> > > > Then you could switch "documents" and "library" in the list, and you
> > > would
> > > > be storing files in the new position (by the definition of
> > > > window.PERSISTENT).
> > > >
> > > > Ian
> > > >
> > > > > >
> > > > > >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> 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 <
> > > iclell...@chromium.org
> > > > >
> > > > > >> wrote:
> > > > > >> > 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=333395on
> > > > > >> 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
> > > > > >> >> > >
> > > > > >> >> >
> > > > > >> >>
> > > > > >>
> > > > >
> > > >
> > >
> >
>
