Is this spec deprecated?

[feross]

From https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

Non-standard
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.

[chaals]

At the moment there are several more or less complete implementations - ironically webkit is the major browser engine that really does not support it.

There was a discussion about this at the recent face to face meeting, because there is another proposal that the same browsers are interested in.

My own understanding is that this specification roughly works now in most browsers, but in predicting the future it is not clear whether people prefer to work on an unprefixed version of this or on something more closely based on the entries API proposal.

Either way, browsers seem to have pretty clearly decided that the functionality is valuable.

[feross]

Sorry for being uninformed -- how does this effort differ from the File API?

File API: https://www.w3.org/TR/file-system-api/
FileSystem API: http://w3c.github.io/filesystem-api/ (this spec)

The url paths are so similar that it's quite confusing. I didn't realize these were two different specs! Can you explain?

[adanilo]

The top document (at w3.org) is not being worked on, it dates back to 2014 and it says "Work on this document has been discontinued and it should not be referenced or used as a basis for implementation". The second document is the editors draft of a work in progress.

[feross]

The top document (at w3.org) is not being worked on, it dates back to 2014

Right. But I think there's confusion in the developer community about this current spec effort. It seems the second document is meant to replace the 2014 effort?

@chaals My own understanding is that this specification roughly works now in most browsers

Is this in reference to this current effort? I've never heard of it before. Are you sure you don't mean this other, third, File API (https://www.w3.org/TR/FileAPI/)?

[feross]

It seems there are 3 specs here:

File API: widely implemented, 92% support
File API (Directories and System): Chrome only, deprecated, 51% support
FileSystem API (this repo): Meant to replace deprecated effort, Browser support unclear, spec status unclear, stalled?

And only the last 2 in that list actually let us have a full filesystem with permanent storage.

Is my understanding correct?

Context: The web really needs a proper filesystem to properly compete with native apps. I'd love to make WebTorrent use the disk instead of in-memory storage, but there's no clear cross-browser solution.

[miketaylr]

File API (Directories and System): Chrome only, deprecated, 51% support

AIUI, that currently lives at https://wicg.github.io/entries-api/, (or at least a subset) and it's supported by Edge and Firefox 49+:

Some Gecko implementation bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=1258489
https://bugzilla.mozilla.org/show_bug.cgi?id=1258490

[chaals]

Mike wrote:

AIUI, that currently lives at https://wicg.github.io/entries-api/, (or at least a subset) and it's supported by Edge and Firefox 49+:

No, the spec is these two, mentioned by @feross:

File API (Directories and System): currently marked deprecated, supported by Firefox/Edge/Blink-based browsers
FileSystem API (this repo): This is the working repo for the spec. At this stage it seems, given the interop, that we should undeprecate it and update it, so we need an editor who wants to do that work.

The discussion I pointed to in the recent meeting minutes was about whether to continue to work from this, or move to the entries-api spec. There was also a discussion about file-writing specs.

[chaals]

@feross asked

Sorry for being uninformed -- how does this effort differ from the File API?

The File API is a subset - it does blobs, input type="file" and a few basic functions.

This filesystem API is one of several efforts over most of a decade to provide a more powerful way to interact with a file system. It was proposed some years ago, implemented in Chrome, and then left to lie around. Quite recently, it was implemented in Firefox and Edge, which is why it is back under discussion.

[feross]

@chaals Yep, aware of the basic File API. Was asking about this File API (https://www.w3.org/TR/file-system-api/). Which folks seem to refer to as the Filesystem API, even though the doc is titled "File API".

I understand how all this fits together now, but the naming was quite confusing at first.

[annevk]

Hmm, pretty sure only Blink supports "File API: Directories and System". Firefox doesn't, at least.

[feross]

@annevk I believe you're correct. So, supposedly Firefox and Edge are implementing the Entries API, which is a subset of "File API: Directories and System", but I haven't seen a browser support matrix for this on any site, like CanIUse.com or MDN, so I think there needs to be better evangelism around these efforts.

Is there any definite information on which browsers support this? The most info I could find is here (https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Firefox_support) and it only discusses Firefox support.

cc @addyosmani

[annevk]

Entries is everyone but Safari at the moment. Primarily for webkitdirectory, which never shipped in Safari, but did elsewhere… Not sure everyone is shipping that yet though, but soon.

[nolanlawson]

AFAICT (someone correct me if I'm wrong) but it looks like webkitEntries and webkitGetAsEntry (aka Entries API) were a one-off implemented for compatibility reasons, hence why MDN marks it as non-standard. That would also explain why we kept the webkit prefix; no sense removing the prefix if nobody wanted to move forward on the API.

Also Entries doesn't have much to do with "filesystem" per se; it's fairly limited to scenarios of e.g. dragging-and-dropping files into an input element.

There's also the directory upload proposal by @aliams which is not implemented by any browser yet.

I think there's a desire from web developers to have some kind of file system access, but it'd be good to nail down what the requirements are, to see if any of the existing proposals even cover the target use cases. E.g. from talking with @mikeal I've heard that one much-desired feature is a streaming interface to and from the filesystem, which could arguably be added to IDB rather than this spec or any similar filesystem spec. @feross are you looking for something similar for WebTorrent?

[jimmywarting]

I've heard that one much-desired feature is a streaming interface

Then you will here it from me too: wish to have ReadableStream and WritableStream Stream API but non of the api supports it (filled an issue here: WICG/entries-api#11)