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] <http://cordova.apache.org/docs/en/3.3.0/cordova_file_file.md.html#File>



On Fri, Jan 31, 2014 at 10:21 AM, Arthur Barstow <art.barstow@nokia.com>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 <http://dev.w3.org/2009/dap/
> file-system/file-writer.html>. The last ED update was 30-Jan-2013 and
> last TR publication was 17-Apr-2012 <http://www.w3.org/TR/2012/WD-
> file-writer-api-20120417/>.
>
> * File API: Directories and System <http://dev.w3.org/2009/dap/
> file-system/file-dir-sys.html>. The last ED update was and last TR
> publication was 17-Apr-2012 <http://www.w3.org/TR/2012/WD-
> file-system-api-20120417/>.
>
> We also have this spec from Arun and Jonas:
>
> * FileSystem API <http://w3c.github.io/filesystem-api/Overview.html>. 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] <http://lists.w3.org/Archives/Public/public-webapps/
> 2014JanMar/0093.html>
> [Aug-2013] <http://lists.w3.org/Archives/Public/public-webapps/
> 2013JulSep/0334.html>
> [April-2013] <http://www.w3.org/2013/04/25-webapps-minutes.html#item13>
>
>
>
>
>
>