[whatwg] Using requestFileSystem to setup mounts

[Kinuko Yasuda]

On Tue, Nov 22, 2011 at 7:30 AM, Glenn Maynard <glenn at zewt.org> wrote:
> 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.

Putting aside the API discussion, actually I like the idea having one shared
isolated filesystem that contains multiple directories/files being dropped in,
as in that way both the UA and script can easily distinguish the set of
dropped files/directories as a single group sharing the same filesystem
object.  I don't think that must be enforced as a part of spec or
recommendation, but I don't think it's strange having multiple
files/directories being dropped in the same virtual root directory either.
(I'm not saying we should weigh rFS approach more than .entries
or getAsEntry)

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

Again I think this could be left to the UA's implementation decision.

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