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