cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommy-Carlos Williams <to...@devgeeks.org>
Subject Re: Configuring the File plugin
Date Tue, 14 Jan 2014 21:05:24 GMT
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
View raw message