On Mon, Mar 31, 2014 at 3:39 PM, Ian Clelland <iclell...@chromium.org>wrote:
> The new File plugin has been in the wild now for almost two months now, and > it seems to be seeing a lot of real-world use (bug reports are coming in to > JIRA almost daily :) ) > > There have been a lot of bugs fixed, and a fair number of people guided > towards new ways of doing things, but there are definitely some recurring > themes, and I think, looking at things pragmatically, that there are some > things that we can do to make the whole file experience better for > developers. > > > ---- ONE ---- > > The first thing has to do with .toURL(), and it's new baby brother, > .toNativeURL(). Originally, the ideal was that .toURL() would always return > a URL with the prefix "cdvfile://", but this has caused problems with a > number of use cases, all involving passing the URL to the webview as a > "src" attribute. The Android code for resolving "src" attributes generally > doesn't pass the URLs back to the application, and so a real file:/// URL > is required. > > Because of this, I introduced .toNativeURL, which will try to return a > file:/// URL, or a content:// URL, and will only return a cdvfile:// URL if > it has no other alternative. I've been providing guidance to developers to > try to use that if they want to use File-plugin-files in video or audio > tags, or even for img tags on Android <= 3.0 > > 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? > > ---- TWO ---- > > The second issue has to do with the filesystem locations which are made > available to Cordova apps. The File plugin provides two sandboxed > filesystem locations, one for persistent files, and one for temporary > files. Files which reside outside of those two locations are not accessible > to the plugin, by default. > > (For comparison, the old version of File would happily access files > anywhere on the device, even well outside of the claimed 'roots') > > This generally works, doesn't cause problems with applications using the > File plugin, and is (I think) still a good idea. It breaks down, however, > when other plugins come in to the mix. Before File was released, I made > changes to FileTransfer, and since, I have changed Camera, and been working > on MediaCapture -- all to ensure that they play within File's sandboxes. > MediaCapture, though, is more difficult, because it's the OS that is > creating the files, and it will create them where it wants to, not where we > think it should. > > I revived the file-system-roots plugin to take care of this problem -- when > installed, it registers several additional file systems, covering other > areas of the device, allowing access to places like "SD Card storage", > "external cache", "internal cache", etc (see the plugin README for all of > FYI: https://github.com/apache/cordova-plugins/tree/master/file-system-roots > the details). It's even possible to register the "root" filesystem, which > re-enables access to the *entire* device. Adding this plugin has worked for > basically everyone who's had a problem with file locations, but it seems > wrong to have to recommend an outside-of-core plugin to fix a problem with > core plugins. > > The question here, I guess -- because a number of people have required this > feature, and there may be additional third-party plugins out there that > will require it as well -- is whether it makes sense to include this > functionality in the core File plugin, or whether to just continue to > recommend it to people whose apps write files in locations outside of the > standard persistent/temporary file systems. > Thoughts, opinions, flames -- all welcomed. Thanks for reading this far :) > I do like adding these by default. Most devs will follow your guidance anyway by use of PERSISTENT and TEMPORARY fs type, and will never "accidently" reach into these other fs roots without meaning to. I like when hybrid apps can do just as much as native equivalents without having to try too hard. > Ian >
