Re: File API - where are the missing parts?

On Sun, Feb 21, 2016 at 3:32 AM, Florian Bösch <pyalot@gmail.com> wrote:

>
> *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
>
> Is the last bullet here really accurate? How can you use existing APIs to
listen to file modifications?

There are also APIs implemented in several browsers for opening a whole
directory of files from a webpage. This has been possible for some time in
Chrome, and support was also recently added to Firefox and Edge. I'm not
sure how interoperable these APIs are across browsers though :(

I would also add that existing APIs does allow partial reads. You can slice
a blob to get a smaller blob, and then read that. Slicing is a cheap
operation and should not copy any data.

Using this you can actually emulate incremental reads, though it is not as
easy as full streaming reads, and it might have some slight performance
differences.



> *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
>
> Another important missing capability is the ability to modify an existing
file. I.e. write 10 bytes in the middle of a 1GB file, without having to
re-write the whole 1GB to disk.

However, before getting into such details, it is very important when
discussing read/writing is to be precise about which files can be
read/written.

For example IndexedDB supports storing File (and Blob) objects inside
IndexedDB. You can even get something very similar to incremental
reads/writes by reading/writing slices.

Here's a couple of libraries which implement filesystem APIs, which support
incremental reading and writing, on top of IndexedDB:

https://github.com/filerjs/filer
https://github.com/ebidel/idb.filesystem.js

However, IndexedDB, and thus any libraries built on top of it, only
supports reading and writing files inside a origin-specific
browser-sandboxed directory.

This is also true for the the Filesystem API implemented in Google Chrome
APIs that you are linking to. And it applies to the Filesystem API proposal
at [1].

Writing files outside of any sandboxes requires not just an API
specification, but also some sane, user understandable UX.

So, to answer your questions, I would say:

The APIs that you are linking to does not in fact meet the use cases that
you are pointing to in your examples. Neither does [1], which is the
closest thing that we have to a successor.

The reason that no work has been done to meet the use cases that you are
referring to, is that so far no credible solutions have been proposed for
the UX problem. I.e. how do we make it clear to the user that they are
granting access to the webpage to overwrite the contents of a file.

[1] http://w3c.github.io/filesystem-api/

/ Jonas