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'm assuming the toURL change you propose wouldn't prohibit the use case you mention, since we could still return cdvfile:// if file:// isn't available. toNativeURL should still exist as a call and *only* return native urls, and toURL would allow native or virtual. So, I'm curious, do we also need a toCdvURL()? Would you ever want to use cdvfile:// when a file:// *is* available? > 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. > That was my suspicion. I think its not a powerful enough reason to not make the change you propose. One option is to support toCdvURL()/toPersistantURL() for the old toURL() behaviour. Another is to acknowledge that the next migration will never be pretty and just address it when it comes (my vote). > > > > > > > > > > > ---- 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 > > > > > >
