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 Fri, 24 Jan 2014 16:52:22 GMT
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 <iclelland@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 <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