You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cordova.apache.org by Ian Clelland <ic...@chromium.org> on 2013/11/05 17:35:06 UTC
New filesystem roots API?
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?
Re: New filesystem roots API?
Posted by Michal Mocny <mm...@chromium.org>.
On Thu, Nov 7, 2013 at 4:47 AM, Brian LeRoux <b...@brian.io> wrote:
> I tend to agree. Keeping this as a standalone extension will give us a
> clear 'thing' to allow devs to shim out if they want to be browser
> compatible. Also, in favor in async.
>
> Brings up a deeper philosphical discussion: should we be providing shims
> for functionality so that our community user land code is browser portable?
> (Eg, noop's or console logs in development)
>
I think so, or at the very least guidance. I'm not sure that we need to
bundle this with plugins, but we could have a repository of helpful code
snippets either in cordova-labs or just in blog posts.
I thought that requestFileSystem + hints would help devs be browser
portable, but I think Andrew&Brian are right that we should instead be
clear that this is a cordova extension, and instead provide guidance on how
to make a browser shim for the cordova extension (or just make our
extensions super obvious how to be shimmed in browser, as I think this one
would be).
>
>
> On Thu, Nov 7, 2013 at 9:11 AM, Andrew Grieve <ag...@chromium.org>
> wrote:
>
> > -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 <mm...@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 <ic...@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?
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: New filesystem roots API?
Posted by Brian LeRoux <b...@brian.io>.
I tend to agree. Keeping this as a standalone extension will give us a
clear 'thing' to allow devs to shim out if they want to be browser
compatible. Also, in favor in async.
Brings up a deeper philosphical discussion: should we be providing shims
for functionality so that our community user land code is browser portable?
(Eg, noop's or console logs in development)
On Thu, Nov 7, 2013 at 9:11 AM, Andrew Grieve <ag...@chromium.org> wrote:
> -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 <mm...@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 <ic...@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?
> > > > >
> > > >
> > >
> >
>
Re: New filesystem roots API?
Posted by Andrew Grieve <ag...@chromium.org>.
-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 <mm...@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 <ic...@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 <ic...@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?
> > > >
> > >
> >
>
Re: New filesystem roots API?
Posted by Ray Camden <ra...@adobe.com>.
On 11/6/13, 1:30 PM, "Michal Mocny" <mm...@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"
And just an FYI, this would be a big win imo. I get asked about this often
enough that I¹ve been meaning to find time to write my own utility for it.
-Raymond Camden
Re: New filesystem roots API?
Posted by Michal Mocny <mm...@chromium.org>.
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 <ic...@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 <ic...@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?
> > >
> >
>
Re: New filesystem roots API?
Posted by Ian Clelland <ic...@chromium.org>.
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 <ic...@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?
> >
>
Re: New filesystem roots API?
Posted by Brian LeRoux <b...@brian.io>.
I'm trying to understand: precisely what does this provide us that
requestFileSystem does not? (Currently.)
Another thing to consider, we need to document the differences from the W3C
proposed standards and get that feedback back to the browser vendors.
On Tue, Nov 5, 2013 at 4:35 PM, Ian Clelland <ic...@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?
>