- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Fri, 6 Apr 2012 13:42:02 +0900
On Fri, Apr 6, 2012 at 12:52 PM, Glenn Maynard <glenn at zewt.org> wrote: > On Wed, Apr 4, 2012 at 11:36 PM, Kinuko Yasuda <kinuko at 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. > I wanted to make it synchronous, but determining the file type (file or directory) usually requires blocking file I/O operation, which could spoil the async nature of this proposal if we perform the blocking stat operation on every drag-enter event. > 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.) > Supporting structured cloning sounds like the right direction to me too. > 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.) > Thanks for showing your support, I hope we can uniformly support Entry both in <input> and native drag-and-drop. > 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. > Yes! > -- > Glenn Maynard > >
Received on Thursday, 5 April 2012 21:42:02 UTC