All sounds great Ian. Awesome work with all of this. That's awesome Bryan! I think file-system-roots fills a giant need, and would be great if it were supported everywhere.
With merging file-system-roots in, it'll be important to have file's docs updated to have links to the iOS / Android guidance pages on where to store things (as linked to in CB-285) On Tue, Apr 1, 2014 at 7:54 AM, Bryan Higgins <br...@bryanhiggins.net>wrote: > I'm in the process of converting the bb10 file plugin to use the exec proxy > rather than clobbering common js. Once that's done, I'll take a look at > adding some additional file system roots. > > > On Tue, Apr 1, 2014 at 10:24 AM, Ian Clelland <iclell...@chromium.org > >wrote: > > > On Tue, Apr 1, 2014 at 10:14 AM, Bryan Higgins <br...@bryanhiggins.net > > >wrote: > > > > > +1 to replacing toURL with toNativeURL behaviour > > > > > > > I think that's what I'll do. I'm also adding a "toInternalURL" method -- > > not because it's necessarily useful for end users, but because we can use > > it as the single method to construct URLs for transport across the > bridge. > > > > > > > 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. > > > > > > > It does provide that; although I haven't enabled it by default. I've been > > pretty wary of allowing JavaScript to arbitrarily access *everything* on > > the entire device that is permitted by the OS. > > > > > > > > > > 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. > > > > > > > That's the whole point of the file-system-roots plugin -- on Android, it > > adds things like sdcard, external cache, external persistent files, > > documetns, etc. On iOS, it gives library, documents, cache, bundle, and a > > couple of non-icloud-synced versions of them. I'd love to get a set of > > useful BlackBerry file system roots as well. > > > > Ian > > > > > > > > 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 > > > > > > > > > > > > > > >
