- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 13 Dec 2011 14:32:15 -0800
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