+1 to replacing toURL with toNativeURL behaviour For accessing the root file system, what I'd personally like is a ROOT filesystem type for requestFileSystem. If the file-system-roots plugin provides that I think we should definitely pull it in.
For the camera and media plugins on BB10 we return a full path relative to the file system root as the native apps save into default locations. I wonder if there is an opportunity to add additional roots which map to default locations for pictures, music and video (maybe also documents?). It seems like that would be super useful for media player apps or downloaders. On Tue, Apr 1, 2014 at 4:50 AM, Anis KADRI <anis.ka...@gmail.com> wrote: > 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 > > >
