cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: Looking at the new File API pragmatically
Date Tue, 01 Apr 2014 08:50:50 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message