[whatwg] getAsEntry(File) was, Re: Using requestFileSystem to setup mounts
ericu at chromium.org
Wed Dec 14 12:18:02 PST 2011
On Tue, Dec 13, 2011 at 2:32 PM, Charles Pritchard <chuck at jumis.com> wrote:
> 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.
> 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.
True; this could be a nice convenience feature, as long as it could be
made read-only and all path information could be scrubbed.
> This is mostly about ease of use for authors working with the file system
> 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.
More information about the whatwg