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.
>
>
>>
>>
>>
>> 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=333395 on
>> 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
>> >> > >
>> >> >
>> >>
>>
