4 ms·

New API for directory picking and drag-and-drop

31 points by cpeterso 11y ago

ryanackley 11y ago
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/fepbnnnkkadjhjahcafoaglimekefifl?hl=en https://chrome.google.com/webstore/detail/readium/fepbnnnkka...
- ape4 11y ago
  I doubt they are inventing a problem just for fun.
  - ryanackley 11y ago
    Have you ever worked on an engineering team?
- jfoster 11y ago
  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.
  - deleted 11y ago
    [deleted]
- rrrx3 11y ago
  It's unfortunate, but this is typical behavior. I really wish it would stop, though.
- deleted 11y ago
  [deleted]
- startling 11y ago
  Historically the iterative approach has led to incomplete, buggy, and vulnerable features that become de facto browser standards because of wide adoption.
binarymax 11y ago
Woohoo looks like I'm getting my wish[0][1]! [0] http://max.io/articles/the-state-of-state-in-the-browser/ http://max.io/articles/the-state-of-state-in-the-browser/ [1] http://w3c.github.io/filesystem-api/ http://w3c.github.io/filesystem-api/
deskamess 11y ago
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.
- saurik 11y ago
  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?
  - deskamess 11y ago
    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.

31 points by cpeterso 11y ago

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/fepbnnnkkadjhjahcafoaglimekefifl?hl=en https://chrome.google.com/webstore/detail/readium/fepbnnnkka...

ape4 11y ago
I doubt they are inventing a problem just for fun.
- ryanackley 11y ago
  Have you ever worked on an engineering team?
jfoster 11y ago
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.
- deleted 11y ago
  [deleted]
rrrx3 11y ago
It's unfortunate, but this is typical behavior. I really wish it would stop, though.
deleted 11y ago
[deleted]
startling 11y ago
Historically the iterative approach has led to incomplete, buggy, and vulnerable features that become de facto browser standards because of wide adoption.

binarymax 11y ago

Woohoo looks like I'm getting my wish[0][1]! [0] http://max.io/articles/the-state-of-state-in-the-browser/ http://max.io/articles/the-state-of-state-in-the-browser/ [1] http://w3c.github.io/filesystem-api/ http://w3c.github.io/filesystem-api/

deskamess 11y ago

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.

saurik 11y ago
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?
- deskamess 11y ago
  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.