- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 9 Apr 2012 17:33:55 -0500
On Mon, Apr 9, 2012 at 3:35 AM, Kinuko Yasuda <kinuko at chromium.org> wrote: > I don't think we should do this. The change would be invasive and could > delay firing a drop event indefinitely if the number of dropped files is > very huge. > This feels like the wrong optimization. It's making this API more cumbersome for all users, for an unlikely case: selecting tons of individual files that can't be stat()'d quickly. Usually, files that are being dropped have been accessed recently (by the windowing system, when the user selected the files), so they're almost always going to be in cache. I think in practice, "delay indefinitely" is an exaggeration. If we keep it asynchronous the Web page could have more control over which > to instantiate when, e.g. it could only show the first few items upon drop > and then keep loading more items asynchronously only when necessary. > That's what DirectoryEntry is for. Adding yet another asynchronous API layer on *top* of Entry to allow dropping lots of individual files feels like an overcomplication, especially when most of the time, even doing that with thousands of files would still be very fast. It also makes it a lot harder to push file work to workers. This: elem.ondrop = function(e) { worker.postMessage({entries: e.dataTransfer.entries}) } becomes something like this: elem.ondrop = function(e) { var items = e.dataTransfer.items; var nextEntry = 0; var entries = []; var gotEntry = function(ent) { if(ent != null) entries.push(ent); if(nextEntry == items.length) { worker.postMessage({entries: entries}); return; } e.dataTransfer[nextEntry].getAsEntry(gotEntry); ++nextEntry; } gotEntry(null); } The point of using workers here would be to avoid all this (with sync APIs)... On Mon, Apr 9, 2012 at 12:21 PM, Eric U <ericu at google.com> wrote: > It might make more sense to store a URL or other locator for the file, > to make it clear that you're storing a reference, not the data itself. > I suppose that storing an Entry could be like storing a capability > [permission to access the file], but that's for the other discussion. > That's how I've always viewed Entry (and File): its existence in your context is what gives you access to the file it represents. URLs can't do that. -- Glenn Maynard
Received on Monday, 9 April 2012 15:33:55 UTC