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

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

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
> 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 Wednesday, 14 December 2011 12:18:02 UTC