unified JS: Entry.toURL

[Becky Gibson <gi...@gmail.com>]

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

Re: unified JS: Entry.toURL

[Filip Maj <fi...@adobe.com>]

Woops, I posted about this in the other thread. I'll repost for
clarification:

Basically: each platform implements file system paths/URIs differently.
iOS had file:///localhost, android and BB just rolled with file://, etc.
The W3C spec recommends an even different way.

To answer your question Becky, what is it that we want, to me, the holy
grail would be
File API code that we could literally copy-paste across platforms and see
it "just work."

What I've seen employed and what I've seen recommended by various people:

- an app: URI. app:/ or app:// or app:/// would be the root of your app
"jail" - leaving it up to the implementations to figure out how to do
that, decoding the paths on the native side, etc. The W3C widget spec I
believe has some similar suggestions with respect to using a widget:// URI.
- using file:///. Then you get an absolute path to the device. Encompasses
cases where you want to mess about the FS outside of your app and globally
on the device. Maybe we could use some kind of convention here but it
could get messy.
- just using absolute or relative URLs, regardless of protocol. Like "/"
or "/cache/".
- I think the recommendation in the latest File API W3C spec draft has
something like http://example.domain/app/ - but this doesn't make much
sense to me.


If we can agree on a convention, with the above as just suggestions, we
would be half way there.

On 12-02-24 2:00 PM, "Becky Gibson" <gi...@gmail.com> wrote:

>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-FIL
>E-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