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
