On Tue, Apr 1, 2014 at 3:28 AM, Ian Clelland <iclell...@chromium.org> wrote:
> On Mon, Mar 31, 2014 at 4:33 PM, Ian Clelland <iclell...@chromium.org > >wrote: > > > On Mon, Mar 31, 2014 at 4:20 PM, Michal Mocny <mmo...@chromium.org> > wrote: > > > >> On Mon, Mar 31, 2014 at 3:39 PM, Ian Clelland <iclell...@chromium.org > >> >wrote: > >> > This is ugly, though, and is going to get worse over time, and become > a > >> > division between Cordova and any platforms which actually implement > the > >> > File API correctly. I'd like to propose switching the behaviour of > >> > .toURL(), to match .toNativeURL -- returning a webview-usable URL by > >> > default -- and implementing some other method or property to get the > CDV > >> > URL when it's necessary. > >> > > >> > >> Everything you've said sounds like its all upside to make the switch. > So > >> I'm curious, when would CDV URL be necessary/useful over file/content > >> urls? > >> > > > > cdvfile:// URLs would still be necessary when dealing with files that > just > > don't *have* an alternate representation. There currently aren't any of > > those, but we could implement virtual file systems entirely inside of a > > plugin, and those would require a cdvfile:// URL to be read. > > > > I think we'd recommend them when saving URLs to persistent storage, if > > there is any chance that the actual files could be moved / migrated, and > we > > could hide that from the user by giving them a more abstract identifier > > than one which specifies a physical location. > > cdvfile://localhost/persistent/my/file.txt might be more durable over > time > > than file:///data/data/com.company.package/files/my/file.txt, perhaps > > across OS upgrades. > > > > Actually, forget all of that. > > Your question had me looking for reasons to advocate users using cdvfile:// > URLs, when perhaps none exist. The truth of the matter is this: The cdvfile > URL has two parts: the filesystem name, and the full path. Those two parts > form a consistent internal representation for all of the types of file that > the plugin can handle, and so all of the internal / native bits of the file > plugin use them almost exclusively. We make sure that every FileEntry and > DirectoryEntry has those parts, and we only need to turn them into a URL > for passing them across the bridge. > > One day someone may discover a great reason to use deliberately use cdvfile > URLs at the application level; until then, they're available, and we can > continue to use them internally to simplify the plugin code, enforce the > sandboxing, and make everything generally more consistent and efficient, > and users shouldn't need to know or care what the URLs in use actually are. > I agree with this as long as the URLs are useable in the WebView (as src attributes for example). If they're not, I also suggest that we return URLs that are useable (file:///, content:/// or whatever) by default. As for filesystems (temp or persistent), I think most developers will use whatever the default is. BUT they should be able to specify where they want to store their data if they feel like it without using a third-party plugin. > > Ian >
