[whatwg] Using requestFileSystem to setup mounts

 On Tue, Nov 22, 2011 at 6:06 AM, Kinuko Yasuda <kinuko at chromium.org> wrote:

> 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)
>

This would lead to interop problems if it's not consistent, though.  For
example, if my application creates ZIP files, and the user drags two files
into the root directory of the ZIP, he wants to put those files at the top
of the ZIP:

/file1.txt
/file2.txt

If the UA creates a virtual directory for that drag, then it'd end up
putting the files in a subdirectory with the name of the virtual directory,
as if a directory was dragged:

/drag-and-drop/file1.txt
/drag-and-drop/file2.txt

> 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.
>

The main point is just that a FileSystem object will always be available,
even if the UA is only exposing one file in a directory which contains
other (inaccessible) files.  Most of the time it wouldn't be used, it just
avoids exceptional cases in the API.  (In other words, Entry.filesystem
would not become nullable.)

-- 
Glenn Maynard

Received on Tuesday, 22 November 2011 08:58:38 UTC