cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: New filesystem roots API?
Date Thu, 07 Nov 2013 09:11:04 GMT
-1 to using requestLocalFileSystem. RLFS is a standard, and what we're
adding here is not a part of it. I think there is value in keeping
Cordova-specific logic separate so that it's easy for devs to know when
they are using an API that is Cordova-specific (as opposed to a polyfill).
That said, I think resolveLocalFileSystemURL() should be extended to allow
creating an Entry for these custom URLs.

+1 async API since some platforms will need to use exec() to implement.





On Wed, Nov 6, 2013 at 2:30 PM, Michal Mocny <mmocny@chromium.org> wrote:

> I think perhaps the motivation here is being lost in the sea of details.
>  Let me attempt to decompose the motivation into very few words (please
> correct me Ian):
>
> * We desire a way for apps to access to "the idiosyncrasies of the various
> platforms -- their media storage, document storage, etc"
> * window.requestFileSystem (currently) cannot do this, but we could extend
> it by adding new FS types.  This would naturally be async.
> * We also want a way to resolve those locations to filesystem:// paths (or
> equivalent) for use with FileTransfer etc.
>   * ..a plugin was recently added to cordova-labs to implement one way of
> accomplishing this, but Ian is suggesting its the wrong way.
>
>
> My answer:
>
> +1 to adding hints to window.requestFileSystem.  (But I'm not 100% on how
> best to extend the API, though.  I kinda like adding a new "hint" parameter
> instead of replacing the FS type, which could perhaps be ignored on
> platforms that don't support it and simply fallback to PERSISTENT?)
>
> async only is fine, but maybe its trivial to add the sync getters
> (window.requestFileSystemPath() or something)?
>
> Either way, it would be very easy to write a userland library that
> implements a single async init() that caches the paths and provides sync
> getters from that point onwards, so app devs don't have to figure that out
> themselves.
>
> -Michal
>
> On Tue, Nov 5, 2013 at 2:10 PM, Ian Clelland <iclelland@chromium.org>
> wrote:
>
> > On Tue, Nov 5, 2013 at 9:32 AM, Brian LeRoux <b@brian.io> wrote:
> >
> > > I'm trying to understand: precisely what does this provide us that
> > > requestFileSystem does not? (Currently.)
> > >
> >
> > I think it currently provides two things, of dubious value:
> >
> > First, it's a synchronous API, so if you need to get a URL to store a
> > document, you could just write:
> >
> > var docsURL = getDocumentsDirectory();
> >
> > and you immediately have a file:/// url that you can use with any of the
> > URL-based APIs (like FileTransfer) to save documents.
> >
> >  Whether the synchronous API is valuable or not is up for debate :) At
> the
> > least, it lets you set that up early in your application, without having
> to
> > wrap the whole app in a callback, or go through hoops with asynchronously
> > testing and setting global variables.
> >
> >
> > Second, and probably more important right now, is that it's currently
> > developed independently of requestFileSystem. Currently, we have
> > getCacheDirectory, getDocumentsDirectory, getTempDirectory, and
> > getDataDirectory, but there is no corresponding 'cache' or 'documents'
> file
> > system. They just return paths like
> > "/var/mobile/some-long-uuid/appname.app/Documents/"
> >
> > This has let us deal with the idiosyncrasies of the various platforms --
> > their media storage, document storage, etc -- without having to write all
> > of the code to handle that through the File API.
> >
> > But I think that I'm going to be doing the bulk of that work anyway. I
> > don't think this will be necessary after we're finished overhauling the
> > FIle plugin; it will be much easier to just add new file system roots for
> > each of these things.
> >
> >
> > > Another thing to consider, we need to document the differences from the
> > W3C
> > > proposed standards and get that feedback back to the browser vendors.
> > >
> >
> > Yep; if there is a legitimate case for these functions -- the sync api,
> or
> > the URL-centric API (as opposed to the FileEntry-centric API), then we
> > should definitely be letting the standards folks and the browser vendors
> > know.
> >
> > Ian
> >
> > >
> > >
> > > On Tue, Nov 5, 2013 at 4:35 PM, Ian Clelland <iclelland@chromium.org>
> > > wrote:
> > >
> > > > During our FIleSystem API brainstorming session, we visited the idea
> of
> > > > having an API to obtain URLs to various file system roots with a
> > > > synchronous call. I was a big fan at the time, but I'm no longer
> > certain
> > > > that it provides any advantages over window.requestFilesystem.
> > > >
> > > > (Most of this code currently lives in the File-extras plugin, but the
> > > idea
> > > > would be to promote this to the File plugin, I believe.)
> > > >
> > > > The API would consist of a set of JS functions, get*URL (currently
> > > > get*Directory) -- getTemporaryURL, getMediaURL, getDocumentsURL, etc.
> > > These
> > > > would return a URL which could then be used directly as a root for
> the
> > > > files stored in it, or passed to window.resolveLocalFilesystemURL to
> > > > retrieve a DirectoryEntry object.
> > > >
> > > > On systems which support filesystem:// URLs, this would probably
> return
> > > > things like filesystem://localhost/temporary/,
> > > > filesystem://localhost/documents/, etc.
> > > >
> > > > On systems which cannot support custom URLs -- BB10, maybe Windows
> > Phone?
> > > > -- this could return usable URLs like local:///path/to/documents/, or
> > > > file:///path/to/documents/
> > > >
> > > > This API is essentially a counterpart to window.requestFileSystem,
> and
> > I
> > > > think that it could be implemented in an asynchronous fashion
> > essentially
> > > > like this:
> > > >
> > > > getDocumentsDirectory = function(callback) {
> > > >     window.requestFileSystem('documents', function(fs)) {
> > > >       callback(fs.root.toURL());
> > > >     });
> > > > });
> > > >
> > > > Questions:
> > > >
> > > > Is there a pressing need for a synchronous version of this, or is the
> > > async
> > > > version above enough?
> > > > Do we believe that other situations will arise where fs.root.toURL
> will
> > > > return a different value than the corresponding get*URL function?
> > > > I think it is better to support new FS roots by adding new HTML
> > > filesystems
> > > > to window.requestFileSystem, rather than just defining new URLs which
> > > > aren't accessable any other way. Am I right in this, or are there
> going
> > > to
> > > > be significant hurdles to adding new roots for things like 'media',
> > > > 'documents', 'cache', etc?
> > > >
> > >
> >
>

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