This is now pushed to dev. I've updated the docs in the plugin as well as
the config.xml that ships with mobile-spec.
(I changed the preference name at the last minute -- I remembered CB-4103,
and the work that went into standardizing on CamelCase for all of the
preference names across platforms)
mobile spec now contains
<preference name="iosPersistentFileLocation" value="Library" />
If you run mobile spec without this, it will terminate with an assertion
failure, and the message
File plugin configuration error: Please set iosPersistentFileLocation in
config.xml to one of "library" (for new applications) or "documents" (for
compatibility with previous versions)
appears in the log. I haven't added the message on plugin install yet, but
that should be done today.
Ian
On Thu, Jan 23, 2014 at 11: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
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>
>> > >
>> >
>>
>
>
