Re: File API - where are the missing parts?

Thank you Florian - I am somewhat puzzled by the development (or the
lack of) in this area. Though it is possible to read a file
incrementally (I routinely deal with files > 1GB) by implementing
file.slice , other parts you are mentioning are dearly missed. Add the
incompatibilities in regard to the internal storage of files (filehandle
anyone?) and Safari's ignorance towards anchored downloads .. and you
have a perfect quagmire ...

Michaela




On 02/21/2016 05:32 AM, Florian Bösch wrote:
> 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
>     Inline image 2 
>
>     Notepad
>     Inline image 3
>
>     Blender
>     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
>     *
>     *
>     *Inline image 5*
>     *
>     *
>     Notepad:
>     *Inline image 6*
>     *
>     *
>     Blender:
>     *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?
>