cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@chromium.org>
Subject Re: New filesystem roots API?
Date Wed, 06 Nov 2013 19:30:25 GMT
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