Migration to WHATWG (of OPFS and AccessHandle)

[annevk]

As discussed in https://docs.google.com/document/d/1RBK5pshKiKWa0drPEPrYwsAmZUELO_23hGM2iJTFiJA/edit we'll migrate part of this specification to the WHATWG, contingent upon WHATWG SG approval.

Checklist:

• Reach WHATWG SG agreement: New standard: File System whatwg/sg#176 (on annevk)
• Create a new repository (or a fork) that subsets the document in this repository, retains the git history, and provides the necessary (optional) infrastructure for local file system access. (on annevk)
• Create a logo (see Add File System logo whatwg/whatwg.org#386) and generally complete the checklist in https://github.com/whatwg/meta/blob/main/NEW-STANDARD.md. (mostly on annevk, but if anyone can help that would be great)
• WPT needs to more clearly split the tests so they are not unnecessarily local file system bound. (mkruisselbrink?)
• Update the document in this repository to account for this new reality. (mkruisselbrink)

I suggest that AccessHandle is integrated after this transition.

cc @domenic @foolip @youennf (sorry, I don't have the handles of all who partook)

[annevk]

A preview of the parts being split out can now be found at https://whatpr.org/fs/1.html.

[dfabulich]

Not sure if this is the right place, but based on a thread on Twitter, I'm going to post some thoughts here.

The web already has a number of heterogenous APIs that, for better or worse, are called "File System" APIs. Most of the APIs listed below have essentially nothing to do with each other.

https://developer.mozilla.org/en-US/docs/Web/API/LocalFileSystem
https://developer.mozilla.org/en-US/docs/Web/API/FileSystem
https://developer.mozilla.org/en-US/docs/Web/API/File_Handle_API
https://developer.mozilla.org/en-US/docs/Web/API/File
https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API

It doesn't help that there's also a proposed "File Handling API," which is ambiguously named because many of these other APIs allow you to do operations on files ("handling the files") and some of them include objects that include the word "Handle." WICG/file-handling#70

I think we need names that can do the following work:

• I think we need to very clearly convey in the names what is a file in the sense of C:\Documents\notes.txt vs. what is a "file" in the sense of "it exists in whatever representation on disk somewhere indistinct and is simply exposed to the origin using a file metaphor".
• We need a name for the spec that will contain the show{FileOpen, FileSave, Directory}Picker() methods, i.e., the ones that Apple chose to not implement. The concepts they share (like FileSystemFileHandle etc.) are untouched by this.
• We must no longer call anything "the File System API." That name has already been used up. Neither should we adopt names that are synonymous to "File System API," including "Native File System" or "Local File System." (All of these FS APIs are native and local.)
  • Whatever we call the APIs, they will always also be named after their objects, e.g. people will always call the https://developer.mozilla.org/en-US/docs/Web/API/File API (which comes from <input> elements) the "File API." The objects can't be renamed for backwards compatibility reasons.

I suggest distinguishing between "user files" and "virtual files," where the origin-private file system uses virtual files and showOpenFilePicker() uses user files.

• The *Picker() APIs could be named the "User File Access API"
• "Origin-Private File System API" is fine, but might be better as "Origin-Private Virtual File System" since there won't be user-visible files associated with it.
• The "File Handling API" could be "Associated File Types API" Renaming File Handling API file-handling#70

[domenic]

I prefer the current proposed name, as it will not require the spec to be renamed if the other parts of (what is currently called) File System Access get two interested implementers and thus also migrate into this spec.

[annevk]

Yeah, we cannot revisit the name of the WHATWG File System at this point. Renaming File System Access to make it clearer it's about exposing the user's local file system seems reasonable however.

[dfabulich]

Does it make sense to be formally called "the WHATWG File System API"? Or to also give it an informal code name like "Houdini," so caniuse etc. could refer to the "Cynosure File System API"?

[annevk]

All WHATWG standards have relatively simple names (see https://spec.whatwg.org/) so File System (sans API) makes sense given its scope. Externally I would expect it to be called the File System Standard or File System Living Standard (equivalent to HTML Standard), perhaps prefixed with WHATWG depending on the context.

The way I see it is that "file system" is a hierarchical data structure consisting of directories and files (and that's what the standard (will) define(s)). Similar to how "file" on the web is also an abstract data structure, that can have a physical backing depending on the entry point used.

[dfabulich]

What about an informal code name, like Houdini? How are we supposed to talk about the difference between "File System" and https://developer.mozilla.org/en-US/docs/Web/API/FileSystem?

Today https://caniuse.com/?search=filesystem shows both https://caniuse.com/filesystem and https://caniuse.com/mdn-api_filesystem

How is anybody supposed to understand the difference? How do I even ask the question of which browsers support "File System"?

[youk]

Don't you already know why and how corporations are eager to own a discourse?

[josephrocca]

Renaming File System Access to make it clearer it's about exposing the user's local file system seems reasonable however.

I don't know about the plausibility of remote file system access as a future extension to this API, but just I'm just mentioning that idea here in case it is relevant to any potential renaming.

Personally I think File System Access API is fine. It has already been renamed once, and I think that was already confusing enough for developers, even though it was quite early in the process. That said, I don't have very strong opinions here.

[domenic]

• Update the document in this repository to account for this new reality. (mkruisselbrink)

I suggest that AccessHandle is integrated after this transition.

Is this still the integration plan? It seems like work is happening in #344 to add access handles, but I thought access handles were going to be added to https://fs.spec.whatwg.org/, not this repository.

I.e. I think the ideal sequence would be:

• Rebase this spec on fs.spec.whatwg.org, deleting all duplicate content
• Add AccessHandles to fs.spec.whatwg.org

but it sounds like the current plan is

• Add AccessHandles to this spec
• Move (or copy?) AccessHandles to fs.spec.whatwg.org
• Rebase this spec on fs.spec.whatwg.org, deleting all duplicate content

[annevk]

@domenic given the reply from @fivedots to #344 (comment) I was expecting that it's still the plan. Your review made me wonder if I'd missed something though.