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. > > > > > > ---- 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 > > >
