Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 2:48 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> Is the last bullet here really accurate? How can you use existing APIs to
> listen to file modifications?
>
I have not tested this on all UAs, but in Google Chrome what you can do is
to set an interval to check a files.lastModified date, and if a
modification is detected, read it in again with a FileReader and that works
fine.


> 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 :(
>
There does not seem to be a standard about this, or is there? It's an
essential functionality to be able to import OBJ and Collada files because
they are composites of the main file and other files (such as material
definitions or textures).


> 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.
>
Good point


> 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/
>
To be clear, I'm referring specifically to the ability of a user to pick
any destination on his mass-storage device to manage his data. This might
not be as sexy and easy as IndexDB & Co. but it's an essential
functionality for users to be able to organize their files to where they
want to have them, with the minimum of fuss.

I'm aware that there's thorny questions regarding UX (although UX itself is
rarely if ever specified in a W3C standard is it?). But that does not
impact all missing pieces. Notably not these:

   - Save a file incrementally (and with the ability to abort): not a UX
   problem because the mechanism to save files exists, it's just
   insufficiently specified to allow for streaming writes.
   - Save as pickable destination: also not a UX problem, the standard
   solution here is to present the user with a standard operating system
   specific file save dialog.
   - Save many files to a user pickable folder: same as above
   - Working directory: this is more something that would go on in the
   background of a UA, it would have to establish a "working directory" per
   tab rather than UA-wide. No UX issues with that.

Additionally this should be minimally UX controversial:

   - Overwrite a file (either previously saved or opened): I think it'd be
   a legitimate implementation of the UX to show an appropriate dialog at the
   time of overwrite that indicates what is overwritten, it's just a
   fast-track to save as pick file (and the UX can be improved by persistence
   of choice if that is deemed an acceptable risk).

So it doesn't strike me that these missing features would create massive UX
problems, indeed, most of them create no UX problem at all.