Consider stronger integration with File System Access

[domenic]

https://wicg.github.io/file-system-access/ has extremely similar API surfaces.

The explainer says

The new Native File System API has a similar API surface, but its main intended usage is to interface with the client’s filesystem and provide access to data that may be outside of the origin’s or even the browser’s ownership. This different focus comes with stricter security considerations and higher performance costs.

However, this is not true for the case of https://wicg.github.io/file-system-access/#sandboxed-filesystem . So I hope that this can be merged into that API, perhaps with some tweaks to File System Access to make sure that it has 100% coverage of the use cases here. /cc @mkruisselbrink.

[domenic]

In particular, you could imagine rebasing all the implementation code currently backing NativeIOManager to instead back the FileSystemDirectoryHandle returned from navigator.storage.getDirectory(). And rebasing all the implementation code currently backing NativeIOFile to instead back the FileSystemFileHandle, FileSystemWritableFileStream, and File objects returned from that FileSystemDirectoryHandle.

You might then want to work with the File System Access editors to ensure feature parity by extending File System Access. E.g., I don't see any equivalent of NativeIO's setLength() or read-with-offset in File System Access, so maybe FileSystemFileHandle would grow equivalent functionality. This is now possible using truncate() and seek() in File System Access. But that seems much better than creating an entirely separate API (cf. #4).

[fivedots]

Hey Domenic, thanks for the detailed feedback!

We are currently talking with the owners of the File System Access API to explore the possibilities. I'll update this issue soon with the conclusions that come out of that.

[jimmywarting]

I'm also very excited about this API but I do not wish for yet another way to work with files... i hope the native file system api can somehow be merged together

[feross]

@fivedots I'm very excited about this API. It would be great to have a performant file API for the web.

A bit of background – The Filesystem Access API is much faster than IndexedDB in our testing, so it's a great addition to the web platform even just in the "sandboxed filesystem" mode. But in our testing the Storage Foundation API is even faster than the Filesystem Access API. For applications that need every bit of performance, like the one I'm building, there's definitely a benefit to having the Storage Foundation API available, even if it's yet another storage API for the web.

[ftreesmilo]

Hey @fivedots any update on your last comment?

[fivedots]

I do have an update, sorry that I forgot to ping this thread, most of the discussion is happening in #4.

The merger options we are looking at are in this document. Later today, we'll publish a more concrete recommendation on how the merger should actually look.

I'll close this issue, since it's become a duplicate of #4. Please let me know what you think in the doc or in that issue!