W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2011

[whatwg] getAsEntry(File) was, Re: Using requestFileSystem to setup mounts

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 13 Dec 2011 14:32:15 -0800
Message-ID: <4EE7D26F.8030809@jumis.com>
On 11/22/2011 8:58 AM, Glenn Maynard wrote:
>
>     > 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.)

I'd like to see a means of getting an "anonymous" FileEntry.
http://www.w3.org/TR/file-system-api/

The purpose being to convert a File object into a read-only FileEntry 
object (with an anonymous FileSystem object).

Currently, a FileEntry can be converted into a File object, but to turn 
a File object into a FileEntry requires a writable FileSystem as well as 
a few calls to file writer methods.
It may be easier to use copyTo instead of FileWriter in some cases, and 
it may be easier to treat dataTransfer items as FileEntry objects 
depending on the application and code paths.

This is mostly about ease of use for authors working with the file 
system api.

Glenn proposed something like getAsEntry as a fix for <input type="file" 
webkitdirectory>, earlier in this thread, but that's not the use case 
I'm focused on.
I suspect that it will come in handy, to be able to work with anonymous 
file systems in the future.

In the meantime, it'd make things a bit easier to use copyTo instead of 
File Writer when a file or blob is available.

-Charles
Received on Tuesday, 13 December 2011 14:32:15 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:38 UTC