- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 21 Nov 2011 13:33:53 -0800
On 11/21/11 8:45 AM, Glenn Maynard wrote:
> On Mon, Nov 21, 2011 at 9:10 AM, Kinuko Yasuda <kinuko at chromium.org
> <mailto:kinuko at chromium.org>> wrote:
>
> On Sun, Nov 20, 2011 at 5:54 AM, Charles Pritchard
> <chuck at jumis.com <mailto:chuck at jumis.com>> wrote:
> > input.ondrop = function(e) {
> > window.requestFileSystem(e.dataTransfer, 0, cb);
> > }
>
> This looks neat, though this would do almost same as what I was
> assuming the internal implementation would do. One clear benefit
> I found in your proposal is the code would make the fact that the UA
> is actually instantiating a new filesystem per drop clearer.
> On the other hand I'm afraid this may slightly complicate the API
> by overloading the requestFileSystem.
>
>
> This API doesn't work, because you can drop multiple directories at
> once; you'd need to pass the DataTransferItem. I don't really see the
> benefit to this approach, though.
Multiple directories still have a shared file system root. Their
relative paths are exposed in webkitdirectory files already.
The benefit is neutered .files object while maintaining compatibility
with existing code bases.
> I didn't look closely enough at the DataTransferItem API before. It
> looks like Entry can be fully supported without removing anything
> currently specced. Add a "getAsEntry" method, which returns FileEntry
> (for kind == "file") or DirectoryEntry (for a new kind == "directory").
What values will Entry.filesystem and Entry.fullpath have?
As synchronous methods, won't these block the user if they need to
confirm permission to mount a directory?
As async methods, these might add a lot of calls to the stack.
> If .entries is supported the script doesn't need to touch the
> .files field thus the UA does not need to populate the .files
> field (though I guess if the UA supports .files field it'd start
> populating the field before it is actually accessed).
>
>
> I don't think .files should ever recurse directories, which makes this
> problem go away.
Recursing directories is the current behavior of webkitdirectory.
>
> But for more generic and
> extended usage (I assume requestFileSystem(window.MOUNT) would
> imply more generic usage) probably we should be more careful about how
> long and when the filesystem lifetime should expire. Maybe we
> could collect
> real usage with the limited mount support and then move things forward
> incrementally. Wdyt?
>
>
> I think drag-and-drop is a good next step for the API.
I think addressing the issues with FileList and webkitdirectory is a
good first step.
-Charles
Received on Monday, 21 November 2011 13:33:53 UTC