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

Consulted with @aliams (thanks!)

Our position is that removing the prefix will require the web to make a change; if the web needs to make a change, we would strongly prefer they instead migrate to a _better_ (more ergonomiclly well-designed approach) than this Entries API.

Issues with this API:

1. The technique for getting entries from `<input>` elements is synchronous (blocking). We actively see performance traces with this on the stack. It can become problematic because the API must aggregate deep directory structures for entries. It also becomes slow if there are a lot of files in a single directory on your local client.
2. Poor ergonomics: there's a weird indirection to get a File from the Entries objects
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.
4. Poor ergonomics: no use of Promises for async stuff :-(
4. 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).
5. Empty folders weren't enumerated (didn’t provide an entry). For customer scenarios where the site wants to clone a local directory into the cloud, empty directories will be missing.

Basically, this feature was hobbled together from partially-implemented parts of an older API, plus a adding a set of extensions as documented in a Wiki. It's not really fit for the Purpose it is primarily used for (directory upload). 

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

Again, if there needs to be a change, we'd prefer not to just unprefix this Entries API.

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