I agree with the plugin broken by default, and requiring From my
experience, doing anything fancy for users to ease migration rarely does
what is intended - and causes more problems, my 2c
FileMigrator plugin is great, externalizes the problem
On Tue, Jan 14, 2014 at 1:10 PM, Andrew Grieve <agri...@chromium.org> wrote:
> Migration isn't possible by default because the current location for
> Android is the root of the SD Card.
>
> The goal here is to put PERSISTENT under Library, but to also make
> other interesting places available via other URLs / FileSystem
> objects.
>
> So far my fav. is to have the plugin broken by default so that users
> will be forced to add a pref to set either old / new location. Really
> don't want new apps being written with data in the wrong spot.
>
> For the case of configuring custom locations, I think a native API is
> more workable than configuration.
>
>
> On Tue, Jan 14, 2014 at 4:05 PM, Tommy-Carlos Williams
> <to...@devgeeks.org> wrote:
> > Sorry…
> >
> > I have been trying not to chicken-little this thread, but I just need
> some clarification on some things.
> >
> > My understanding, please correct me if I am wrong:
> >
> > The “old" location on iOS is not the best location for files the dev
> doesn’t want exposed, but it *is* where they should be if the dev wants
> them accessible via iTunes
> >
> > Assuming this is correct, I have some questions:
> >
> > 1. What if that’s where the dev *wants* the files to go?
> > 2. Could files still be backed up by iCloud if they were in the new
> location?
> >
> >
> > It feels like making assumptions about what kinds of files developers
> are using the File API for.
> >
> > :/
> >
> > - tommy
> >
> >
> >
> > On 15 Jan 2014, at 7:09 am, Ian Clelland <iclell...@chromium.org> wrote:
> >
> >> 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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>
