cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: Configuring the File plugin
Date Tue, 14 Jan 2014 19:59:33 GMT
Ya I like the single preference. So, I think we agree that new plugin
locations are opt in via upgrade (regardless of config). We can also see
that plugin persistence locations are also only available by an opt in
upgrade.

I'm thinking that migration *might* be the use case but this is not well
thought out yet either. It would appear given things like iCloud that a
data migration is only really going to happen for our users if they get a
server involved.

So, why do we want to configure it again? I'm still not seeing it.



On Tue, Jan 14, 2014 at 11:45 AM, Michal Mocny <mmocny@chromium.org> wrote:

> On Tue, Jan 14, 2014 at 2:14 PM, Brian LeRoux <b@brian.io> wrote:
>
> > So, for arguments sake, is
> >
> > 1. Storing files in wrong place in 3.3.0 so don't upgrade. Versioning was
> > one of the wins with moving to plugins.
> >
>
> Would this mean that no existing apps could ever upgrade the plugin without
> losing user data?  Would we want to support the old File plugin for much
> longer, then?
>
> This option isn't unreasonable so long as apps churn at a good rate and/or
> existing apps have no complaints about the current platform/plugin
> implementations and can stick with those for a long time to come.
>
>
> > 2. Storing files in new places: config won't help us b/c you still need
> > code to persist to those new places (for old things that want to use new
> > things see #1)
> >
>
> If I understand this point, I think you mean that we cannot support old+new
> without plugin code bloat?  Well, since the new plugin implementations are
> more flexible and not hardcoding the mapping to type -> location on disk, I
> think a config preference of some kind actually is enough to support both
> mappings.
>
>
> >
> > Is migrating data from old locations to new ones a consideration? (This
> > again does not have anything to do with adding new config as I would
> > understand it.)
> >
>
> Maybe?.. but this would have to happen on each device on first run with the
> new version of the plugin.
>
> Without the app's direct involvement we would need to delay deviceready /
> pluginsready while we run the upgrade process of moving files around, and
> that may take a while (and is risky?).
>
> Also, not sure that we should just blindly move *all* files from Documents
> to Library since that would mean they all disappear from iCloud/iTunes, and
> while I think thats the right call for HTML Filesystem, it is a side effect
> that may not be 100% correct for all current use cases.
>
> I think this could be a useful strategy for apps to update from using old
> location to new location, since the app knows how/when to do the work.
>
>
> >
> > Configuration surface is effectively mutable conditional bug surface. We
> > add waaay too much of it as is and I'm really not convinced there is a
> > valid use case yet.
> >
>
> Fair enough, which is why Ian&Andrew are trying to cut this down to a
> single preference instead of the huge set of possible permutations Ian
> previously just threw over the fence for consideration.
>
>
> >
> >
> >
> > On Tue, Jan 14, 2014 at 10:48 AM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> >
> > > I'll let Ian answer, but my understanding:
> > >
> > > - We are storing some files in the wrong place right now, but we need
> to
> > > continue storing in the wrong place by default for apps to not break on
> > > upgrade
> > > - We want to store files in a few new places that haven't been
> supported
> > > until now
> > > - We want to roll this out in a way that leaves the door open for
> future
> > > changes without this much pain ever again
> > >
> > >
> > > 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?
> > > >
> > > >
> > > > 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