On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda <kin...@chromium.org> wrote:
> A follow up about this proposal: > > Based on the feedbacks we got on this list we've implemented the following > API to do experiments in Chrome: > DataTransferItem.getAsEntry(in EntryCallback callback) > Does this actually need to be async? The only information you need to create the Entry are the filename and the file type (file or directory), which the browser can load before performing the drop, so no file I/O is needed here. which takes a callback that returns FileEntry or DirectoryEntry if it's for > drop event and the item's kind is 'file'. > Right now it's prefixed therefore its actual name in Chrome is > 'webkitGetAsEntry'. > We use kind=='file' in a broader definition here (i.e. a file path which > can be either regular file or directory file) and didn't add a specific > kind for directories. > (Btw we've also implemented DataTransferItem.getAsFile(), so apps can call > either getAsFile or webkitGetAsEntry for kind=='file' item) > If getAsEntry is synchronous, a separate getAsFile method isn't needed. You can just say transfer.getAsEntry().file(), and reduce the API surface area a bit. As for lifetime and toURL() issue, which was the biggest concern in the > past discussion, we decided not to support toURL/resolveURL on Entries for > drag-and-drop, so that it won't leak reference or expose GC period. A > dragged file can be accessed only while the script has the Entry instance > (as well as we do for File object). > I agree with this. toURL makes some sense within the sandboxed filesystem, but it just doesn't for non-sandboxed use. > We eventually aim to support structured cloning of Entries but it's not there yet. This is sort of a separate issue, but it would be nice to eventually get full structured cloning support, with support for File/Entry into IndexedDB. That is, let me store an Entry into IndexedDB, so I can later restore it and regain access to the file. For example, if a user grants my music player web app access to his MP3 collection, I can store the resulting Entry in IndexedDB (or History), and the user can load my web app later and start playing music, without having to re-open the directory every time. This needs further thought around user expectations of how long access grants last, but hopefully it can be worked out eventually. (We don't need to go into this here; just mentioning it again while it's on my mind, so people can be thinking about it.) As for <input type="file"> support I am thinking about adding "AsEntries" > attribute (so that we do not need to do the automatic recursive > files/directories retrieval when the attribute is specified) and "entries" > field, but haven't done anything yet. (Open to further suggestions) > This sounds right, too. This would make File access from <input> obsolete. (File would still avoid at least one asynchronous call for non-recursive use cases, though, so people will still use it.) I hope we can get valuable user feedbacks (as well as from yours) based on > the implementation. > This sounds good. Once we've played around with this for a while, we can start thinking about how to safely expose write access. -- Glenn Maynard