[whatwg] Using requestFileSystem to setup mounts

(Sorry for my slow response)

On Wed, Nov 23, 2011 at 1:58 AM, Glenn Maynard <glenn at zewt.org> wrote:

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

The UA can simply puts the file1.txt and file2.txt in the virtual 'root'
directory if Entry.fullPath matters.

Or if we don't go along the requestFileSystem approach (and I'm not
convinced to go that way) I don't think Entry.fullPath really matters as
far as the user scripts can tell that the entries given as .entries (or
.items) are the top-level ones that are being dropped.



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

Oh if you meant Entry.filesystem must always have a valid value I totally
agree with it.


>
> --
> Glenn Maynard
>
>

Received on Monday, 28 November 2011 06:18:38 UTC