[whatwg] Using requestFileSystem to setup mounts

I wish people wouldn't randomly split threads.  This isn't a different
conversation.

On Mon, Nov 21, 2011 at 9:10 AM, Kinuko Yasuda <kinuko at chromium.org> wrote:

> On Sun, Nov 20, 2011 at 5:54 AM, Charles Pritchard <chuck at jumis.com>
> wrote:
> > input.ondrop = function(e) {
> >  window.requestFileSystem(e.dataTransfer, 0, cb);
> > }
>
> This looks neat, though this would do almost same as what I was
> assuming the internal implementation would do.  One clear benefit
> I found in your proposal is the code would make the fact that the UA
> is actually instantiating a new filesystem per drop clearer.
> On the other hand I'm afraid this may slightly complicate the API
> by overloading the requestFileSystem.
>

This API doesn't work, because you can drop multiple directories at once;
you'd need to pass the DataTransferItem.  I don't really see the benefit to
this approach, though.

I didn't look closely enough at the DataTransferItem API before.  It looks
like Entry can be fully supported without removing anything currently
specced.  Add a "getAsEntry" method, which returns FileEntry (for kind ==
"file") or DirectoryEntry (for a new kind == "directory").

getAsFile would be unchanged, returning File for kind == "file" and null
for anything else (including kind == "directory").

This is also a convenient way to expose access (a bit later on).  Add an
async method getAsWritableEntry(onsuccess, ondenied) method.  On success,
the callback supplies a new FileEntry or DirectoryEntry which allows write
access.  Note that while this needs to be async, since it may ask the user
for permission, the read-only method can be synchronous like getFile.  (In
practice the UA would probably ask "do you want to allow the page to write
to these files", not ask for each individual file, so it doesn't ask over
and over if the caller is requesting write access to several
simultaneously-dropped files.)

If .entries is supported the script doesn't need to touch the
> .files field thus the UA does not need to populate the .files
> field (though I guess if the UA supports .files field it'd start
> populating the field before it is actually accessed).
>

I don't think .files should ever recurse directories, which makes this
problem go away.

In the drag-and-drop context it's clear that the permission and namespace
> must go away once the context goes away.


The permission should be attached to the Entry object, not the browsing
context.  If you send an Entry to a SharedWorker, the SharedWorker should
still have access to the file if the context that sent it is closed.  If
*all* contexts attached to the SharedWorker go away, then the worker will
be terminated, and that's when you'll lose the permission as a side-effect
of losing the object.

This is clear and consistent, and scales cleanly to future APIs (in both
Window and Worker) exposing Entry objects from various sources.

But for more generic and
> extended usage (I assume requestFileSystem(window.MOUNT) would
> imply more generic usage) probably we should be more careful about how
> long and when the filesystem lifetime should expire.  Maybe we could
> collect
> real usage with the limited mount support and then move things forward
> incrementally.  Wdyt?
>

I think drag-and-drop is a good next step for the API.

-- 
Glenn Maynard

Received on Monday, 21 November 2011 08:45:05 UTC