Re: File API - where are the missing parts?

On Tue, Feb 23, 2016 at 7:12 AM, Florian Bösch <pyalot@gmail.com> wrote:
> 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.

That is in violation of the spec. file.lastModified should be constant
for the lifetime of the file object.

Sadly the File object is grossly missnamed. It doesn't represent a OS
filesystem file at all. It's more like large chunk of data with some
metadata. Really we likely should have just had Blob and NamedBlob :(

>> 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).

There is no standard for this no. But there's clearly appetite for one
given that all browsers now implement this functionality.

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

I suspected you were. But you should then know that the Google Chrome
proposals that you were referring to does not relate to those use
cases at all.

This is a very common misconception sadly.

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

Indeed. This would be a solvable problem without introducing new UX
concepts. The main missing piece here is likely the lack of Stream
objects, which is what you'd want for incremental writing.

Fortunately that part is much closer to a solved problem these days.

So likely the main thing holding this use case up is simply having a proposal.

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

I'm not sure I understand how this is different from what <a
download="..."> does?

Is the problem that some browsers does not let the user choose
directory to save in?

It would be interesting to know why browsers don't let users choose
directory for <a download>, and if they'd have concern supporting
something like <a download letuserchoosedirectory>

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

I think there's a couple of UX concerns here.

For normal save-as, we can ensure that the user is in full control
over the saved file name and directory. But if the website can write
50 files at once, it becomes much harder for the user to track what
names things are saved as, and which files comes from a website and
which files the user already had.

The other problem is what to do if a file with a website provided name
already exists. Do you silently just append some sort of suffix? Do
you ask the user if they want to overwrite?

Generally, this use case might be a lot easier/safer to handle if we
let the user choose the name of a new directory, and save all the
files in that directory. That way the user knows that all files in
that directory were created by the website, and we won't have to worry
about collisions.

Another thing that I think would be good to keep in mind when drafting
a solution to this is that it'd be nice to allow the website to save a
deep hierarchy. I.e. the website wouldn't provide a list of files to
be saved, but a list of files and directories, where the directories
can contain other files and directories.

> 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).

This seems like the same usecase as the "save in a user-picked folder"
use case. If the user pick a location where a file already exists,
we'd simply ask the user if they want to overwrite.

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

Feel free to write up proposals :)

/ Jonas

Received on Tuesday, 23 February 2016 20:27:30 UTC