[whatwg] Drag-and-drop folders/files support with directory structure using DirectoryEntry

[Kinuko Yasuda]

On Fri, Apr 6, 2012 at 12:32 AM, Eric U <ericu at google.com> wrote:

> On Wed, Apr 4, 2012 at 9: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)
> >
> > 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)
> >
> > 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).  We eventually aim to support
> > structured cloning of Entries but it's not there yet.
> >
> > Each Entry returned by this API has following properties:
> > * is read-only.
> > * has the dropped file/directory name (not a full path) in its
> > Entry.name, which must also match with the basename of Entry.fullPath.
> > * should not expose the actual platform path, but how exactly its
> fullPath
> > should look is implementation dependent. (In our implementation it always
> > appears as a top-level path, e.g. '/foo' for a file/directory 'foo')
> >
> > Example:
> > If we drop multiple files/directories like following:
> >  /User/kinuko/Photos/travel/thailand/
> >  /User/kinuko/Photos/holiday2012/
> >  /User/kinuko/Photos/photos.txt
> >
> > We'll get three kind=='file' items in dataTransfer.items, and
> > calling getAsEntry (webkitGetAsEntry) on each item allow us to get
> > FileEntry or DirectoryEntry and to recursively traverse its child
> > files/subdirectories with full control if it's directory.
>
> "full control" still doesn't include modification, though, right?
> It's read-only all the way down?


Oh yes. It's read-only all the way down.  Sorry I chose the confusing word.


>  >  var items = e.dataTransfer.items;
> >  for (var i = 0; i < items.length; ++i) {
> >    if (items[i].kind == 'file') {
> >      items[i].webkitGetAsEntry(function(entry) {
> >        displayEntry(entry.name + (entry.isDirectory ? ' [dir]' : ''));
> >        ...
> >      });
> >    }
> >  }
> >
> > 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)
> >
> > I hope we can get valuable user feedbacks (as well as from yours) based
> on
> > the implementation.
> >
> >
> > On Sat, Nov 19, 2011 at 7:37 AM, Glenn Maynard <glenn at zewt.org> wrote:
> >
> >> On Fri, Nov 18, 2011 at 1:36 AM, Kinuko Yasuda <kinuko at chromium.org
> >wrote:
> >>
> >>> I would say the approach has a bloating per-page bookkeeping problem
> but
> >>> not a 'leak'.
> >>
> >>
> >> It's a reference leak: an object which remains referenced after it's no
> >> longer needed.  I'm not aware of anything standardized in the platform
> with
> >> this problem.  Also, a lot of toURL use cases would simply not work with
> >> drag-and-dropped files (being able to modify the URL to access
> neighboring
> >> files; storing the URL for access in a future session).
> >>
> >> Anyway, do you still agree that having Entry structured clonable is a
> good
> >> idea?  I'm only really worried about toURL if it causes structured
> cloning
> >> of Entry to not happen, since I think the latter is a much more solid
> and
> >> useful approach, and more consistent with what we already have.
> >> (Half-solutions make me nervous, because they have a tendency to delay
> full
> >> solutions.)
> >>
> >> --
> >> Glenn Maynard
> >>
> >>
>