On Tue, Nov 22, 2011 at 7:30 AM, Glenn Maynard <gl...@zewt.org> wrote: > On Mon, Nov 21, 2011 at 4:33 PM, Charles Pritchard <ch...@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 > >