There is a note in the incubator-cordova-js readme TODOs about the fileURL
api:
Normalize Entry.toURL return values. iOS returns "file://localhost" +
fullPath, Android returns "file://" + fullPath, BlackBerry returns just
fullPath
The current implementation is:
Entry.prototype.toURL = function() {
// fullPath attribute contains the full URL
return this.fullPath;
};
Now, to me fullPath represents a just that a path. A URL includes a host
name and domain. The latest editor's draft of the File API: Directories
and System spec () isn't entirely clear:
toURL
Returns a URL that can be used to identify this entry. Unlike the URN
defined in
[FILE-API<http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#bib-FILE-API>],
it has no specific expiration; as it describes a location on disk, it
should be valid at least as long as that location exists.
Do we want to spec out the URL format/scheme? It would be quite nice if
these could be edited and manipulated easily, as with normal filesystem
paths.
How and where can these URLs be used? Can they be interchangeable with
online URLs for the same domain?
Proposal currently under discussion:
- Use a format such as filesystem:
http://example.domain/persistent-or-temporary/path/to/file.html .
- URLs should be usable for anything that online URLs can be used for,
whether they appear in online or filesystem-resident web pages.
- However, they can only be used by the origin that owns the filesystem.
No other origin can e.g. reference another origin's filesystem in an IMG
tag.
I think Android and BB are returning file:// as part of the fullPath. iOS
is not. The old iOS implementation of toURL() (formerly toURI) was:
DirectoryEntry.prototype.toURI = function(mimeType, successCallback,
errorCallback) {
return "file://localhost" + this.fullPath;
};
Now, I can go through the iOS file code and append file:// or
file://localhost (I think I need the localhost in order for these to work
in webView but I'd have to go back and test) to all of the fullPath entries
I return and then remove them in all of the device implementations. But
my question is why are we returning URL's in a variable that is name a
"path"?
What is it that we want and why?
thanks,
-becky
