[whatwg] Using requestFileSystem to setup mounts

[Charles Pritchard]

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