cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: Looking at the new File API pragmatically
Date Mon, 31 Mar 2014 20:33:19 GMT
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.


>
>
> >
> > ---- TWO ----
> >
> > The second issue has to do with the filesystem locations which are made
> > available to Cordova apps. The File plugin provides two sandboxed
> > filesystem locations, one for persistent files, and one for temporary
> > files. Files which reside outside of those two locations are not
> accessible
> > to the plugin, by default.
> >
> > (For comparison, the old version of File would happily access files
> > anywhere on the device, even well outside of the claimed 'roots')
> >
> > This generally works, doesn't cause problems with applications using the
> > File plugin, and is (I think) still a good idea. It breaks down, however,
> > when other plugins come in to the mix. Before File was released, I made
> > changes to FileTransfer, and since, I have changed Camera, and been
> working
> > on MediaCapture -- all to ensure that they play within File's sandboxes.
> > MediaCapture, though, is more difficult, because it's the OS that is
> > creating the files, and it will create them where it wants to, not where
> we
> > think it should.
> >
> > I revived the file-system-roots plugin to take care of this problem --
> when
> > installed, it registers several additional file systems, covering other
> > areas of the device, allowing access to places like "SD Card storage",
> > "external cache", "internal cache", etc (see the plugin README for all of
> >
>
> FYI:
> https://github.com/apache/cordova-plugins/tree/master/file-system-roots
>
>
> > the details). It's even possible to register the "root" filesystem, which
> > re-enables access to the *entire* device. Adding this plugin has worked
> for
> > basically everyone who's had a problem with file locations, but it seems
> > wrong to have to recommend an outside-of-core plugin to fix a problem
> with
> > core plugins.
> >
> > The question here, I guess -- because a number of people have required
> this
> > feature, and there may be additional third-party plugins out there that
> > will require it as well -- is whether it makes sense to include this
> > functionality in the core File plugin, or whether to just continue to
> > recommend it to people whose apps write files in locations outside of the
> > standard persistent/temporary file systems.
>
>
> > Thoughts, opinions, flames -- all welcomed. Thanks for reading this far
> :)
> >
>
> I do like adding these by default.
>
> Most devs will follow your guidance anyway by use of PERSISTENT and
> TEMPORARY fs type, and will never "accidently" reach into these other fs
> roots without meaning to.  I like when hybrid apps can do just as much as
> native equivalents without having to try too hard.
>
>
> > Ian
> >
>

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