- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 21 Nov 2011 17:30:26 -0500
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
Received on Monday, 21 November 2011 14:30:26 UTC