File API - where are the missing parts?

These are the existing standardized ways to deal with files locally.

*File API*

URL: https://www.w3.org/TR/FileAPI/
Status: Active
Support: Broad, partial, http://caniuse.com/#feat=fileapi

Covers Blobs (data/mime bags), Blob URLs, Files (name, size, modified),
FileLists, FileReader (reading in blobs and files in different formats).


*HTML5 File Input*

URL:
https://html.spec.whatwg.org/multipage/forms.html#concept-input-type-file-selected
Status: Active
Support: probably good, not tracked.

Allows to get a FileList from an input element


*HTML5 anchor download (and name)*

URL:
Status: Active
Support: All except Safari

Allows to pass a blob URL to an anchor element for download.


*What this covers*

   - Read one or many files in their entirety in one go (in python that
   would be open('foobar').read())
   - Save a completed binary string in its entirety in one go to the
   download folder (no overwrite)
   - Listen to file modifications

*What is missing*

   - Read a file incrementally (and with the ability to abort)
   - Save a file incrementally (and with the ability to abort)
   - Overwrite a file (either previously saved or opened)
   - Save as pickable destination
   - Save many files to a user pickable folder
   - Working directory

*Rationales for the missing parts*

It is difficult for web based productivity applications to compete with
native applications in terms of UX/convenience/productivity without the
missing parts.

*Incremental reading*: When dealing with large files that are undesirable
to load into JS memory whole. Current problem is: exceeding JS memory
and/or large delays.

*Incremental writing*: When dealing with writing large files whose content
is undesirable to keep in JS memory whole. When dealing with
computationally intensive data to produce. Current problem is: exceeding JS
memory and/or large delays and/or loosing data, also bad UX (click "prepare
file", click "save").

*Overwriting a file*: When working on content that should be saved to disk
overwriting the existing load/save location. Current problem: all files in
download folder named myfile.txt, myfile (1).txt, myfile (2).txt, myfile
(3).txt, myfile (N).txt etc.


MS Office
[image: Inline image 2]

Notepad
[image: Inline image 3]

Blender
[image: Inline image 4]


*Save as pickable destination*: When wanting to write a file to a
destination that is somewhere else than the download folder. Current
problem is: #1 save #2 go to downloads #3 move file to where it needs to go
#4 repeat


MS Office

*[image: Inline image 5]*

Notepad:
*[image: Inline image 6]*

Blender:
*[image: Inline image 7]*


*Save many files to a user pickable folder*: Some formats such as Collada
or OBJ refer external files (images). For file collection export/save like
that it is required to write many files in a folder. Current problem: not
possible at all.

*Working directory*: When saving/opening a file in one webapp, and then
using a different webapp. It is hard on the user to always jump around
between folders to open/save a file.

*Questions*

   1. There have been two now abandoned standards that covered some of this
   functionality (https://www.w3.org/TR/file-system-api/ and
   https://www.w3.org/TR/file-writer-api/). What are the successor
   standards to these?
   2. If there are no successors, why not?
   3. Are the rationales for the missing parts clear and uncontroversial?