Re: [File System APIs] If one is good, then two must be better?

Hi Art,

For what it's worth, the File API: Directories and System is also
implemented (and supported) by Apache Cordova[1]. The implementation is
essentially complete for mobile applications on Android, iOS and FireOS,
with nearly-complete support on Blackberry and Windows Phone.

While our plugin registry was counting downloads, it was the
most-downloaded plugin for the platform by a wide margin, so I believe it
is being used actively.

I don't know if Cordova should count as a browser implementation for the
purposes of this WG, but we are implementing the APIs and making them
available to (hybrid) web application developers.

[1] <>

On Fri, Jan 31, 2014 at 10:21 AM, Arthur Barstow <>wrote:

> Hi Eric, Arun, Jonas, All,
> During the review of the first draft of WebApps' proposed charter
> extension, Marcos raised (indirectly) a question [1] about the plan for
> WebApps' various file system APIs and I agreed to followup.
> We have the two specs that Eric edits:
> * File API: Writer <
> file-system/file-writer.html>. The last ED update was 30-Jan-2013 and
> last TR publication was 17-Apr-2012 <
> file-writer-api-20120417/>.
> * File API: Directories and System <
> file-system/file-dir-sys.html>. The last ED update was and last TR
> publication was 17-Apr-2012 <
> file-system-api-20120417/>.
> We also have this spec from Arun and Jonas:
> * FileSystem API <>. The
> last update of the ED was 2-Oct-2013 and this spec has not been published
> as a TR.
> My understanding is the only implementation of Eric's APIs is Chrome. I do
> not know the implementation status of Mozilla's spec. If anyone has
> additional information about the implementation status or plans of either
> effort, please let us know.
> The last discussion about the relationship between these different efforts
> was August 2013 [Aug-2013] and prior to that, there was some discussion
> during the April 2013 f2f meeting [April-2013].
> Ultimately, I think there is broad agreement a single API that is broadly
> implemented and deployed would be `best` (f.ex. reduces FUD, lightens
> implementation costs, lightens deployment costs, etc.). Although I would
> (still) like to be optimistic we can agree to converge on a single API,
> previous discussions about this do make me skeptical ...
> Eric, Arun, Jonas - can you agree and commit to converge your efforts,
> f.ex. just have a single API?
> All - if we can't get a commitment to converge these efforts:
> * Do we want to continue both efforts (and thus reflect this in the
> charter update)?
> * Should we take a vote/poll with a goal to select a single effort and to
> stop work on the effort that has less support?
> * Something else?
> Comments are welcome.
> -Thanks, ArtB
> [1] <
> 2014JanMar/0093.html>
> [Aug-2013] <
> 2013JulSep/0334.html>
> [April-2013] <>

Received on Friday, 31 January 2014 21:33:44 UTC