I like this approach. Its explicit, obvious change, and the existing
plugins fulfill the extensibility story just fine.
On Thu, Jan 23, 2014 at 8:52 AM, Ian Clelland <iclell...@chromium.org>wrote:
> Okay, I'm going to do this on dev branch, then:
>
> File plugin will be *broken by default* on iOS.
> Developers will need to add a preference to their apps' config.xml files.
> It will look like this:
> <preference name="ios-persistent-file-location" value="library">
> or
> <preference name="ios-persistent-file-location" value="documents">
> unless someone has a really good bikeshed colour.
>
> On iOS, CDVFile will throw an exception on initialize if this isn't set.
> The error in the log will be as explicit as I can make it about what failed
> and how to fix it.
>
> I'm dropping the idea of adding any more XML configuration for supporting
> exotic third party plugins. That can be done in native code, by calling the
> right methods on the file plugin to add new filesystems. No XML; no
> javascript: if a plugin needs a special FS root, it can add it. If an app
> needs it, the easiest way for now will be to create a plugin that adds it.
>
>
>
> On Tue, Jan 14, 2014 at 4:14 PM, Shazron <shaz...@gmail.com> wrote:
>
> > 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
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >
> > >
> >
>
