Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of iclelland@google.com
 designates 209.85.219.47 as permitted sender)
MIME-Version: 1.0
Sender: iclelland@google.com
In-Reply-To: 
 <CADVgkyNaZYL7u548wer1U_AJZBh8ajSS+Wu3pd5Z7v5w6by+8g@mail.gmail.com>
References: 
 <CAK_TSXLgU5GZ1TMYDaP4mE3TBJqrzf8S1qwHqt00JVhg2+yO=Q@mail.gmail.com>
 <CADVgkyNaZYL7u548wer1U_AJZBh8ajSS+Wu3pd5Z7v5w6by+8g@mail.gmail.com>
From: Ian Clelland <iclelland@chromium.org>
Date: Tue, 5 Nov 2013 11:10:48 -0800
Message-ID: 
 <CAK_TSXK7fnNEQS3jU1RKOMDSp2skwMgVPa9GSTL=xxDRVcKjEw@mail.gmail.com>
Subject: Re: New filesystem roots API?
To: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=047d7b472a4087eccc04ea72cbdf

--047d7b472a4087eccc04ea72cbdf
Content-Type: text/plain; charset=UTF-8

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?
> >
>

--047d7b472a4087eccc04ea72cbdf--