Re: [w3ctag/design-reviews] Files and Directory Entries API with webkit prefixes! (#215)

It looks like most of @travisleithead's notes apply to the way that entries appear on the HTMLInputElement rather than the interfaces of the types that are exposed (and might be re-used for other FS-like operations). 

> 1. The technique for getting entries from <input> elements is synchronous (blocking). 

^^^ Specific to HTMLInputElement

> 2. Poor ergonomics: there's a weird indirection to get a File from the Entries objects

^^^ Not specific to HTMLInputElement. However, this turns out to be useful; you may want to be able to persist a reference to a file distinct from the file itself. Consider an API which grants some permission for the local file system. The user opens "foo.png" for editing. The web app can persist the reference to the file distinct from the bits, so that when the web page is visited again the filename can be presented in e.g. File > Recently Used and the file re-opened.

> 3. Poor ergonomics: folder path information was added to the flat-list structure. This didn't mesh well with developer's intuitive method for an iterative or recursive approach to "traversing" directories.

^^^ Specific to HTMLInputElement. The rest of the API allows traversal.

> 4. Poor ergonomics: no use of Promises for async stuff :-(

^^^ As noted, these could be added to the types, if there was belief that these types were not dead ends.

> 5. The Entries API has "bolted on" access points that spread into a variety of other objects (e.g., has to extend File to provide *getEntries access points).

^^^ HTMLInputElement and DataTransferItem. 

> 6. Empty folders weren't enumerated (didn’t provide an entry). 

^^^ Specific to HTMLInputElement. Empty directories would be present using the traversal.

> Our attempt at a better design is here: https://wicg.github.io/directory-upload/proposal.html

Yep. It's a cleaner API. Unfortunately, none of the browser vendors (including Microsoft) have yet elected to implement and ship it. :(


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/215#issuecomment-362126582