search

WICG / file-system-access

Expose the file system on the user’s device, so Web apps can interoperate with the user’s native applications.
https://wicg.github.io/file-system-access/
Other
659 stars 65 forks source link

Cloud drive considerations #123

Open foolip opened 4 years ago

foolip commented 4 years ago

"Native" is right there in the name of the spec, but it seems unavoidable to deal with some issues related to cloud drives. The way I came to think of this was when looking at "Files" on iOS, where "iCloud Drive", "On My iPhone" and "Google Drive" are all options when you're downloading something. Two of those are backed by cloud storage.

The concrete createWriter() says that "any changes made through writer won’t be reflected in the file represented by fileHandle until its close() method is called" and how this might be implemented using a temporary file. Can this be efficiently implemented with cloud drives?

It would also be a good idea to check if appending, inserting and overwriting is possible to make efficient. If an implementation would have to download the whole file and upload a replacement, that could end up using more bandwidth than the developer expected.

The most concrete thing to do here is probably to ask for API review from someone familiar with at least iCloud Drive, Google Drive and OneDrive.

mkruisselbrink commented 4 years ago

Appending and inserting aren't efficient even for the native file system, due to safe browsing concerns that are "forcing" us to have this atomic-writes-only model. But agreed that cloud-backed file systems are an important use case to consider, and it would be good to have somebody familiar with those look at the API.

tomayac commented 4 years ago

Somewhat related, I just noticed that iCloud Drive/Documents is considered a system directory on macOS Chrome. I can't open individual files from there. Is this WAI?

mkruisselbrink commented 4 years ago

Not intentional at least. Mind filing a chromium bug?