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)

[feross]

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

Streaming reads are already possible today via drag-drop or a File Input. On the other hand, the following are not currently possible, and are extremely important for the web platform:

1. Streaming writes to files on disk.

• Right now, to save files to disk in WebTorrent, we stream data into pre-allocated typed arrays, wrap those in a Blob, URL.createObjectUrl, then click that link. This requires the entire data to live in memory until it's ready to be saved.
• Streaming writes would let us do file transfers over WebRTC and offer "save this file" functionality without keeping the whole file data in memory.

2. Persistent file/folder access.

• To explain this use case I'll just quote:

Today, if a web site wants to create experiences involving local files (document editor, image compressor, etc.) they are at a disadvantage to native apps. A web site must ask the user to reopen a file every time they want to edit it. After opening, the site can only save changes by re downloading the file to the Downloads folder. A native app, by comparison, can maintain a most recently used list, auto save, and save files anywhere the user wants. (from WICG/writable-files)

The best attempt to address these both issues is actually WICG/writable-files, which I quoted from above. There is a more detailed explainer about the idea here: https://github.com/WICG/writable-files/blob/master/EXPLAINER.md

[kirtangajjar]

@annevk @nolanlawson @feross Any updates on the spec? Last commit is 2 years ago and the it doesn't seem to be implemented by major browsers as well. Is there any specific cause for delay?

[annevk]

The change since #8 (comment) is that now all browsers implement the Entries API as far as I know.

The document this repository is for is still Chrome-only and nobody else is interested.

[ameesme]

It would be nice to have some communication from the @GoogleChrome team to see if they're still planning on keeping this API, or rather their specific extension, implemented in Google Chrome. There is no mention of a deprecation in the specific feature-page for Blink.

Even though the spec is deprecated, many services (in production) make use of it, https://mega.nz/ for example.

[annevk]

cc @RByers

[pwnall]

Just ran into this thread while looking for the other old file system API.

The Chrome team is currently investing in the Native File System API - spec | blog post.

[annevk]

Maybe you can first clean up this one?

[mkruisselbrink]

Not sure what there is to clean up in this spec? As far as I know there are no browsers implementing this, no browsers have ever implemented this, and no browsers are planning to implement this spec.

I'm not entirely sure what the history is behind this spec, but other than updating the status to make it clear that this isn't something anybody is working on this spec there doesn't seem to be much to be done?

(Confusingly enough this thread started by linking to an API that is unrelated to this spec, so maybe the "this one" you're referring to is that other API?)

[annevk]

Yeah, my bad. That is what I meant.

For this specific repository though, that should be archived and marked obsolete somehow as this is indeed not happening.

[LJWatson]

Ping @plehegar

Looks like File System didn't transfer from WebPlat to WebApps.

If @mkruisselbrink is correct and no-one is implementing or intending to, then it would be good to do as @annevk suggests.