[whatwg] Using requestFileSystem to setup mounts

[Glenn Maynard]

On Mon, Nov 21, 2011 at 4:33 PM, Charles Pritchard <chuck at jumis.com> wrote:

> **
> 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.
>

It would be strange to drag in multiple directories and to have it exposed
as a virtual directory containing the dragged files.  It could be done, but
it's inconsistent with the design of DataTransfer, and it feels unnatural.
I don't know what you mean by "compatibility with existing code bases"; the
compatibility is no different than a getAsEntry/getAsWritableEntry API
would be.

Also, remember that DataTransfer objects can be filled in
programmatically.  You can do, for example:

dt.items.add("hello world", "text/plain"); // already supported
dt.items.add(myFile); // already supported
dt.items.add(myFileEntry); // new DataTransferItemList.add(Entry data)
method
dt.items.add(myDirectoryEntry);

The requestFileSystem approach doesn't fit with DataTransfer's design very
naturally.

(Adding a File would be equivalent to adding a FileEntry containing the
File; both would just create a DataTransferItem with a kind of "file".)

 What values will Entry.filesystem and Entry.fullpath have?
>

Each Entry would have a dummy FileSystem object attached to it, in order to
fill out the Entry.filesystem API, but all it would contain is the file
itself.

Entry.fullPath would be the same as Entry.name, prefixed with "/".

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.
>

Async methods (eg. theoretically getAsWritableEntry) is adding no more
calls than would be added by a similar async requestFileSystem call, which
is also async.

getAsEntry gives read-only access; as with getAsFile, there's no additional
permission prompt.  Both methods could be async if we really want to allow
for separate permissions prompting even for read-only access (though that's
awkward UI, especially *during* a drag).  Either way, it's no more code for
users than a requestFileSystem call.

 Recursing directories is the current behavior of webkitdirectory.
>

Yes, this should go away if possible, or at least not be propagated to
other browsers.  It's not a scalable approach, as we discussed earlier.

-- 
Glenn Maynard