Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: callback-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of fil@adobe.com designates
 64.18.1.35 as permitted sender)
From: Filip Maj <fil@adobe.com>
To: "callback-dev@incubator.apache.org" <callback-dev@incubator.apache.org>
Date: Mon, 27 Feb 2012 14:02:40 -0800
Subject: Re: Bug in FileSystem.js
Thread-Topic: Bug in FileSystem.js
Thread-Index: Acz1m4bRjGfo4d3fRSKkEBbqGHFRLw==
Message-ID: <CB713BE6.5A95%fil@adobe.com>
In-Reply-To: 
 <CADjNb+mzxK+P-9U7g+wNTs9t+d_96dR1v0LFZiWGycQXmbYC=g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


>Making this change gets me further in the iOS update.   However, I don't
>understand why the other platforms are returning a URL in the fullPath
>parameter.  Will start/continue a thread on that.
>
>-becky

This is left-over baggage from previous implementations. Figuring out a
good way to abstract would be nice.

Basically: each platform implements file system paths/URIs differently.
The W3C spec recommends an even different way. 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.

In all honesty, I have little preference to either of these. As long as it
is consistent :)

For 1.5, let's leave the current baggage and let it "just work." Moving
forward, let's document and discuss this, let our community know, and fix
it.