Return-Path: X-Original-To: apmail-cordova-dev-archive@www.apache.org Delivered-To: apmail-cordova-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C628D10AB7 for ; Tue, 14 Jan 2014 19:14:58 +0000 (UTC) Received: (qmail 28871 invoked by uid 500); 14 Jan 2014 19:14:58 -0000 Delivered-To: apmail-cordova-dev-archive@cordova.apache.org Received: (qmail 28805 invoked by uid 500); 14 Jan 2014 19:14:58 -0000 Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cordova.apache.org Delivered-To: mailing list dev@cordova.apache.org Received: (qmail 28797 invoked by uid 99); 14 Jan 2014 19:14:57 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 19:14:57 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of brian.leroux@gmail.com designates 209.85.223.177 as permitted sender) Received: from [209.85.223.177] (HELO mail-ie0-f177.google.com) (209.85.223.177) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 14 Jan 2014 19:14:51 +0000 Received: by mail-ie0-f177.google.com with SMTP id ar20so895510iec.8 for ; Tue, 14 Jan 2014 11:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=XN1RyDokvCQLSKGWhquar/QVjgHogbdBaWB/Vn/UU8o=; b=BCYibG6JTXHYaKdZAclMeZcgQLdb8ulWwuHpZjbk7mXj4efawucHx1ew0+6jiNfJHj SuVcBSWCfTFIyRo9yZkJlbKg5vQVn6GW5JOFr5EfJtCCW+2hYlkUZEJc4Ix5sRYmg6Ze m4UO1Qu4wY2gy03spqnf8VL/UMV3MMjP/pD9TgxeV+QllYgHQyJFoMAXsAvo+0fM5gWJ sRP+3rvcNQRzBF0Stky+zNPgs/3+4Uv4mSbsTgO9fXy5FBPxmDpxdKj5c43fqNH4GzCD wNG1OqAeyuX3TCMOPe4qauMo52mX9NO6eCwGGak8n0L6uSBFZPZTS7WznBZ6UvnIwRA3 5vBg== MIME-Version: 1.0 X-Received: by 10.50.72.36 with SMTP id a4mr26904596igv.40.1389726870441; Tue, 14 Jan 2014 11:14:30 -0800 (PST) Sender: brian.leroux@gmail.com Received: by 10.50.87.38 with HTTP; Tue, 14 Jan 2014 11:14:30 -0800 (PST) In-Reply-To: References: Date: Tue, 14 Jan 2014 11:14:30 -0800 X-Google-Sender-Auth: b3QOjBGY2QoZkTVhgR0OqErb7Ns Message-ID: Subject: Re: Configuring the File plugin From: Brian LeRoux To: "dev@cordova.apache.org" Content-Type: multipart/alternative; boundary=047d7bdcab2c72953404eff300ca X-Virus-Checked: Checked by ClamAV on apache.org --047d7bdcab2c72953404eff300ca Content-Type: text/plain; charset=ISO-8859-1 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. 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) 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.) 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. On Tue, Jan 14, 2014 at 10:48 AM, Michal Mocny 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 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 > >wrote: > > > > > On Tue, Jan 14, 2014 at 10:52 AM, Andrew Grieve > > >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. > > > > >> ) > > > > >> > > > > >> 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: > > > > >> > > > >> 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 > > > > > > 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 > > > > > wrote: > > > > >> > > > > > >> >> Will any of the following work? > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> xhr.open("GET","cdvfile://localhost/persistent/data.txt"); > > > > >> >> > > > > >> >> > > > >> >> 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). > > > > >> > > > > > >> > > > > > >> >> > > > > >> >> > > > >> >> target="_blank">Review Site > > > > >> >> > > > > >> > > > > > >> > 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 > > 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: > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > prefix="cdvfile://localhost/temporary" src="cache" /> > > > > >> >> > > > > > >> >> > > prefix="cdvfile://localhost/persistent" src="Documents" /> > > > > >> >> > > > > > >> >> > > prefix="content://" /> > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > or > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > prefix="cdvfile://localhost/temporary" src="cache" /> > > > > >> >> > > > > > >> >> > > prefix="cdvfile://localhost/persistent" src="Documents" /> > > > > >> >> > > > > > >> >> > > prefix="content://" /> > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > (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: > > > > >> >> > > > > > > >> >> > > > > > >> >> > > type="local-filesystem" > > > > >> >> > > prefix="cdvfile://localhost/temporary" > > > > >> >> > > src="Temporary" /> > > > > >> >> > > > > > >> >> > > type="local-filesystem" > > > > >> >> > > prefix="cdvfile://localhost/persistent" > > > > >> >> > > src="Documents" /> > > > > >> >> > > > > > > >> >> > > and then, in a later version, we could change the default > for > > > new > > > > >> >> > projects > > > > >> >> > > to > > > > >> >> > > > > > > >> >> > > > > > >> >> > > type="local-filesystem" > > > > >> >> > > prefix="cdvfile://localhost/temporary" > > > > >> >> > > src="Temporary" /> > > > > >> >> > > > > > >> >> > > type="local-filesystem" > > > > >> >> > > prefix="cdvfile://localhost/persistent" > > > > >> >> > > src="Library" /> > > > > >> >> > > > > > >> >> > > 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 > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> > > > > > > > > > > --047d7bdcab2c72953404eff300ca--