cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Looking at the new File API pragmatically
Date Tue, 01 Apr 2014 22:55:03 GMT
All sounds great Ian. Awesome work with all of this.

That's awesome Bryan!
I think file-system-roots fills a giant need, and would be great if it were
supported everywhere.

With merging file-system-roots in, it'll be important to have file's docs
updated to have links to the iOS / Android guidance pages on where to store
things (as linked to in CB-285)


On Tue, Apr 1, 2014 at 7:54 AM, Bryan Higgins <bryan@bryanhiggins.net>wrote:

> I'm in the process of converting the bb10 file plugin to use the exec proxy
> rather than clobbering common js. Once that's done, I'll take a look at
> adding some additional file system roots.
>
>
> On Tue, Apr 1, 2014 at 10:24 AM, Ian Clelland <iclelland@chromium.org
> >wrote:
>
> > On Tue, Apr 1, 2014 at 10:14 AM, Bryan Higgins <bryan@bryanhiggins.net
> > >wrote:
> >
> > > +1 to replacing toURL with toNativeURL behaviour
> > >
> >
> > I think that's what I'll do. I'm also adding a "toInternalURL" method --
> > not because it's necessarily useful for end users, but because we can use
> > it as the single method to construct URLs for transport across the
> bridge.
> >
> >
> > > For accessing the root file system, what I'd personally like is a ROOT
> > > filesystem type for requestFileSystem. If the file-system-roots plugin
> > > provides that I think we should definitely pull it in.
> > >
> >
> > It does provide that; although I haven't enabled it by default. I've been
> > pretty wary of allowing JavaScript to arbitrarily access *everything* on
> > the entire device that is permitted by the OS.
> >
> >
> > >
> > > For the camera and media plugins on BB10 we return a full path relative
> > to
> > > the file system root as the native apps save into default locations. I
> > > wonder if there is an opportunity to add additional roots which map to
> > > default locations for pictures, music and video (maybe also
> documents?).
> > It
> > > seems like that would be super useful for media player apps or
> > downloaders.
> > >
> >
> > That's the whole point of the file-system-roots plugin -- on Android, it
> > adds things like sdcard, external cache, external persistent files,
> > documetns, etc. On iOS, it gives library, documents, cache, bundle, and a
> > couple of non-icloud-synced versions of them. I'd love to get a set of
> > useful BlackBerry file system roots as well.
> >
> > Ian
> >
> > >
> > > 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
> > > > >
> > > >
> > >
> >
>

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