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 Thu, 23 Jan 2014 16:52:47 GMT
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 <shazron@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 <agrieve@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
> > <tommy@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 <iclelland@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 <
> iclelland@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 <
> > iclelland@chromium.org
> > >>>>>> wrote:
> > >>>>>
> > >>>>>> On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve <
> > >>> agrieve@chromium.org
> > >>>>>>> wrote:
> > >>>>>>
> > >>>>>>> On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland <
> > >>>> iclelland@chromium.org
> > >>>>>>
> > >>>>>>> wrote:
> > >>>>>>>> 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".
> > >>>>>>>
> > >>>>>>> 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
<
> > >>>>> 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=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
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message