Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of iclelland@google.com designates
 209.85.219.41 as permitted sender)
MIME-Version: 1.0
Sender: iclelland@google.com
In-Reply-To: 
 <CAK_TSX+8kNO2j5SZWbvbSEjQWH3eFpQh_7fAXBux_y-HvFFXGQ@mail.gmail.com>
References: 
 <CAK_TSXKa4L2ynsFpXPWTDta3GzimoYjuD23cjuXjPbV1P8e76Q@mail.gmail.com>
 <CADVgkyOgApq8aeHxkhtMMtWHm8UKj4AAONKTChW=Obcs9jNYyw@mail.gmail.com>
 <CAKP6k2vrLx+YTM=b3_KUZgPwpAgm1q2OejGJWx+STKQC0Wg4mw@mail.gmail.com>
 <CAK_TSXKKXV_AC3PBu0vQCGa=j5cLy9=CRhtx1OhHZA263WZ6xg@mail.gmail.com>
 <CABiQX1Wgmh6POVjKBa1_t6Fr5HWPV9XA6zC660Vu3KhCBOXQ5w@mail.gmail.com>
 <CAK_TSXKS07npYb=XHnB5VeYqJUOim0SXH2qmdVBsmU-yms+9Ow@mail.gmail.com>
 <CABiQX1XJNa+8KpMk+rTaf+n_jArnMfX4MsTqGoKy5AqGBgPhtw@mail.gmail.com>
 <CAK_TSX+Ev851RZt6ACrsFypYYsRDi-uZAr-J5N4Gc4vZzA_cSw@mail.gmail.com>
 <CADVgkyPTcTDQSMmPfT+OzN6os+tp4ZDMpEyK0qyz_Cz6rzcqCw@mail.gmail.com>
 <CAK_TSXKLmDT2Na4xvyHJm_KJYraLTzHRxf12FFWOOqJppSFoWA@mail.gmail.com>
 <CADVgkyMuxJSup6wtzJ4REe9QaauG-SzoeVfPRbg6Rgea7Sz2=Q@mail.gmail.com>
 <CAK_TSXKREEjNp3XZk2mZwGG1i91V8Sr-NqPxG4c8KquKXKgMyQ@mail.gmail.com>
 <56413FAA-C311-4E37-B8E7-BBEEA17CD49F@devgeeks.org>
 <CABiQX1VpWDhB19=2oh9RJAWz_64ABL7xe_VCY8vbN+x5kXHJ3A@mail.gmail.com>
 <CAE6O_-ZaaYQjP2EzmoHvCPYx+QtdcxmPF3cQjunt4ncNncfA+w@mail.gmail.com>
 <CAK_TSX+8kNO2j5SZWbvbSEjQWH3eFpQh_7fAXBux_y-HvFFXGQ@mail.gmail.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Fri, 24 Jan 2014 11:52:22 -0500
Message-ID: 
 <CAK_TSXKc6Kdxf_oEV2tVyPT2T5m6V8=L6cJ3kTqw3NorhbCXFQ@mail.gmail.com>
Subject: Re: Configuring the File plugin
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b2e4c02d2429204f0ba2f6b

--047d7b2e4c02d2429204f0ba2f6b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=3D"iosPersistentFileLocation" value=3D"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>wrot=
e:

> 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=3D"ios-persistent-file-location" value=3D"library">
> or
> <preference name=3D"ios-persistent-file-location" value=3D"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 fail=
ed
> 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 t=
he
> 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=E2=80=A6
>> > >
>> > > I have been trying not to chicken-little this thread, but I just nee=
d
>> > some clarification on some things.
>> > >
>> > > My understanding, please correct me if I am wrong:
>> > >
>> > > The =E2=80=9Cold" location on iOS is not the best location for files=
 the dev
>> > doesn=E2=80=99t 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=E2=80=99s 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 developer=
s
>> > 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 ge=
t
>> 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-shape=
d
>> > >>> things,
>> > >>>> but it needs to be configurable to be useful.
>> > >>>>
>> > >>>> #3 is less important at the moment, but becomes more compelling i=
f
>> 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=3D"IosUseLegacyFileSystemPath" value=3D"tru=
e" />)
>> > >>>>>>>>>
>> > >>>>>>>>> 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 nee=
d
>> 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 thei=
r
>> > >>> 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 ap=
p,
>> > >>> 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 configur=
e
>> > >>>> their
>> > >>>>>>>>> own paths might put too much of a burden on them (they'd hav=
e
>> to
>> > >>>>> learn
>> > >>>>>>>>> where files should go, and then also figure out how our conf=
ig
>> > >>>>> syntax
>> > >>>>>>>>> works).
>> > >>>>>>>>>
>> > >>>>>>>>
>> > >>>>>>>> True. The simple case should be as simple as possible. Ideall=
y,
>> > >>>> 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 t=
o
>> 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=3D argument:
>> > >>>>>>>>> <filesystem name=3D"documents"
>> > >>>>>>>>>    type=3D"local-filesystem"
>> > >>>>>>>>>    prefix=3D"cdvfile://localhost/documents"
>> > >>>>>>>>>    src=3D"Documents" />
>> > >>>>>>>>>
>> > >>>>>>>>> If the goal is for these to be customizable, then it's not
>> that
>> > >>>>>>>>> flexible to use pre-defined values in the src=3D argument.
>> Perhaps
>> > >>>>>>>>> instead of using config.xml, the File plugin could have a
>> > >>>>>>>>> registerFileSystemRoot(name, type, prefix, rootPath) functio=
n
>> > >>> that
>> > >>>>>>>>> could be used for this purpose. That way plugins could compu=
te
>> > >>>> 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 specializ=
ed
>> > >>> 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=3D"filesystems"
>> > >>>> value=3D"temporary,documents,assets,library"
>> > >>>>>> />
>> > >>>>>>
>> > >>>>>> Then you could switch "documents" and "library" in the list, an=
d
>> 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 anywhe=
re
>> > >>>> 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=3D"cdvfile://localhost/persistent/1.png"/>
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> xhr.open("GET","cdvfile://localhost/persistent/data.txt");
>> > >>>>>>>>>>>
>> > >>>>>>>>>>> <link rel=3D"stylesheet" type=3D"text/css"
>> > >>>>>>>>>>> href=3D"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=3D"cdvfile://localhost/temporary/site/temp.html"
>> > >>>>>>>>>>> target=3D"_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 configuratio=
n'
>> > >>>>>>> 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=3D333395on
>> > >>>>>>>>> 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 tha=
t
>> > >>>>> would
>> > >>>>>>>>> define
>> > >>>>>>>>>>>> the
>> > >>>>>>>>>>>>> names of the installed filesystems available to a Cordov=
a
>> > >>>>> app,
>> > >>>>>>> along
>> > >>>>>>>>>>> with
>> > >>>>>>>>>>>>> their type, the URL prefix to use, and any other require=
d
>> > >>>>>> details
>> > >>>>>>>>> (like
>> > >>>>>>>>>>>>> *where the files live*). Something like this:
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> <widget>
>> > >>>>>>>>>>>>>  <filesystems platform=3D"android">
>> > >>>>>>>>>>>>>    <filesystem name=3D"temporary" type=3D"local-filesyst=
em"
>> > >>>>>>>>>>>>> prefix=3D"cdvfile://localhost/temporary" src=3D"cache" /=
>
>> > >>>>>>>>>>>>>    <filesystem name=3D"persistent" type=3D"local-filesys=
tem"
>> > >>>>>>>>>>>>> prefix=3D"cdvfile://localhost/persistent" src=3D"Documen=
ts"
>> > >>> />
>> > >>>>>>>>>>>>>    <filesystem name=3D"content" type=3D"content-filesyst=
em"
>> > >>>>>>>>>>>>> prefix=3D"content://" />
>> > >>>>>>>>>>>>>  </filesystems>
>> > >>>>>>>>>>>>> </widget>
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> or
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> <widget>
>> > >>>>>>>>>>>>>  <feature name=3D"File">
>> > >>>>>>>>>>>>>    <filesystems platform=3D"android">
>> > >>>>>>>>>>>>>      <filesystem name=3D"temporary"
>> > >>> type=3D"local-filesystem"
>> > >>>>>>>>>>>>> prefix=3D"cdvfile://localhost/temporary" src=3D"cache" /=
>
>> > >>>>>>>>>>>>>      <filesystem name=3D"persistent"
>> > >>> type=3D"local-filesystem"
>> > >>>>>>>>>>>>> prefix=3D"cdvfile://localhost/persistent" src=3D"Documen=
ts"
>> > >>> />
>> > >>>>>>>>>>>>>      <filesystem name=3D"content"
>> > >>> type=3D"content-filesystem"
>> > >>>>>>>>>>>>> prefix=3D"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=3D"temporary"
>> > >>>>>>>>>>>>>    type=3D"local-filesystem"
>> > >>>>>>>>>>>>>    prefix=3D"cdvfile://localhost/temporary"
>> > >>>>>>>>>>>>>    src=3D"Temporary" />
>> > >>>>>>>>>>>>> <filesystem name=3D"persistent"
>> > >>>>>>>>>>>>>    type=3D"local-filesystem"
>> > >>>>>>>>>>>>>    prefix=3D"cdvfile://localhost/persistent"
>> > >>>>>>>>>>>>>    src=3D"Documents" />
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> and then, in a later version, we could change the defaul=
t
>> > >>>> for
>> > >>>>>> new
>> > >>>>>>>>>>>> projects
>> > >>>>>>>>>>>>> to
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> <filesystem name=3D"temporary"
>> > >>>>>>>>>>>>>    type=3D"local-filesystem"
>> > >>>>>>>>>>>>>    prefix=3D"cdvfile://localhost/temporary"
>> > >>>>>>>>>>>>>    src=3D"Temporary" />
>> > >>>>>>>>>>>>> <filesystem name=3D"persistent"
>> > >>>>>>>>>>>>>    type=3D"local-filesystem"
>> > >>>>>>>>>>>>>    prefix=3D"cdvfile://localhost/persistent"
>> > >>>>>>>>>>>>>    src=3D"Library" />
>> > >>>>>>>>>>>>> <filesystem name=3D"documents"
>> > >>>>>>>>>>>>>    type=3D"local-filesystem"
>> > >>>>>>>>>>>>>    prefix=3D"cdvfile://localhost/documents"
>> > >>>>>>>>>>>>>    src=3D"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 o=
f
>> > >>>> our
>> > >>>>>>>>> existing
>> > >>>>>>>>>>>>> devs.
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>> Ian
>> > >>>>>>>>>>>>>
>> > >>>>>>>>>>>>
>> > >>>>>>>>>>>
>> > >>>>>>>>>
>> > >>>>>>>
>> > >>>>>>
>> > >>>>>
>> > >>>>
>> > >>>
>> > >
>> >
>>
>
>

--047d7b2e4c02d2429204f0ba2f6b--