Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of drkemp@google.com designates
 209.85.220.179 as permitted sender)
MIME-Version: 1.0
Sender: drkemp@google.com
In-Reply-To: 
 <CANpVHHwxrrtbTSYQM6OAZbFROpLuGQb-kpWvrVXpFGyxtJau8A@mail.gmail.com>
References: 
 <CAK_TSX+97kOGzo9Q7DqQy0EH6PN6who0nC6Od=eC3VdDWXcJUw@mail.gmail.com>
	<CAEeF2TesYpLtqSJe63LTG-1etSUGwp=JJ6Shfr6P-xnTGNAu5w@mail.gmail.com>
	<CAK_TSXKcphk2o4_h88U2Fq_2NGy3V-KqoGix-+3fr4XaBwFckA@mail.gmail.com>
	<CAK_TSXLhPeaOebD90yx0D+jXxWpfgjur=EvVmXf9rsvDabrvDw@mail.gmail.com>
	<CANpVHHwxrrtbTSYQM6OAZbFROpLuGQb-kpWvrVXpFGyxtJau8A@mail.gmail.com>
Date: Tue, 1 Apr 2014 09:39:13 -0400
Message-ID: 
 <CAMTxO42xbndmqS9QtjJ5DoCrhX=4pkqk1mP=EZZdLWc3hAQevg@mail.gmail.com>
Subject: Re: Looking at the new File API pragmatically
From: David Kemp <drkemp@chromium.org>
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b342d302f750b04f5fb4b81

--047d7b342d302f750b04f5fb4b81
Content-Type: text/plain; charset=UTF-8

So in summary....
 make toURL() return the same thing that toNativeURL() does now.
 do nothing to toNativeURL()
 maybe later add a toCdvURL()

If thats correct, then +1


On Tue, Apr 1, 2014 at 4:50 AM, Anis KADRI <anis.kadri@gmail.com> wrote:

> On Tue, Apr 1, 2014 at 3:28 AM, Ian Clelland <iclelland@chromium.org>
> wrote:
>
> > On Mon, Mar 31, 2014 at 4:33 PM, Ian Clelland <iclelland@chromium.org
> > >wrote:
> >
> > > On Mon, Mar 31, 2014 at 4:20 PM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> > >
> > >> On Mon, Mar 31, 2014 at 3:39 PM, Ian Clelland <iclelland@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
> >
>

--047d7b342d302f750b04f5fb4b81--