New API for directory picking and drag-and-drop | Hacker News Reader

New API for directory picking and drag-and-drop

jwatt.org

31 pointscpeterso10 comments

I have built a chrome app[1] that uses the webkitdirectory feature of chrome. No performance issues whatsoever. Also, we have never received a single complaint from our 500k users about its performance.

It would make life easier for developers if Mozilla took an iterative approach. Implement it the Chrome way, then work with Google and Microsoft to implement a new standard.

[1] https://chrome.google.com/webstore/detail/readium/fepbnnnkka...

From the article, it sounds to me as though the webkitdirectory performance issue would only become a problem with excessively large trees of directories & files. So, as you mention, in 99% (or more!) of cases it won't be a problem.

Should they go with it, then? I don't know. Ultimately, I think, as you suggest, just getting something common to all major browsers that mostly works is more important than getting this absolutely perfect. Unfortunately, that doesn't seem to be what any of the browser vendors are aiming for.

Historically the iterative approach has led to incomplete, buggy, and vulnerable features that become de facto browser standards because of wide adoption.

It's unfortunate, but this is typical behavior. I really wish it would stop, though.

I doubt they are inventing a problem just for fun.

Have you ever worked on an engineering team?

Hijacking this thread for a download question.

Currently, to download a file you click on the link and the browser pushes the data to the native (not sandboxed) file system. Your code does not see any of the data.

Instead of an automated download, is there a way, on a user initiated download request to just get a handle to a native file (not sandboxed) and populate the native file yourself. Ideally we could then implement a faster download with multiple range requests against multiple storage end points. Or make other custom browser side transformations on the data.

Why can't you do these things against a sandboxed file, and then move the file at the end of the download out of the sandbox? Isn't this in fact exactly what Mega does?

I am not sure what mega does... is their source open? I guess I should just try it. My concerns were having a large enough sand box (files could be 1G+, and many of them) and if there is, even for a short time, a 2x storage hit. Then the second hit of copying (not moving) from sandbox to local or remote drive.

Woohoo looks like I'm getting my wish[0][1]!

[0] http://max.io/articles/the-state-of-state-in-the-browser/

[1] http://w3c.github.io/filesystem-api/

Reply on news.ycombinator.com