..and we are now discussing how best to balance config flexibility vs
config grok-ability
On Tue, Jan 14, 2014 at 1:48 PM, Michal Mocny <mmo...@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 <iclell...@chromium.org
>> >wrote:
>>
>> > On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve <agri...@chromium.org
>> > >wrote:
>> >
>> > > On Tue, Jan 14, 2014 at 10:38 AM, Ian Clelland <
>> iclell...@chromium.org>
>> > > wrote:
>> > > > On Mon, Jan 13, 2014 at 9:16 PM, Andrew Grieve <
>> agri...@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 <
>> iclell...@chromium.org
>> > >
>> > > >> wrote:
>> > > >> > On Mon, Jan 13, 2014 at 3:21 PM, Jesse <purplecabb...@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 <
>> > > iclell...@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
>> > > >> >> > >
>> > > >> >> >
>> > > >> >>
>> > > >>
>> > >
>> >
>>
>
>
