On 1/12/12 12:53 PM, Arun Ranganathan wrote:
On Jan 12, 2012, at 6:58 AM, Kyle Huey <m...@kylehuey.com
<mailto:m...@kylehuey.com>> wrote:
On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard <gl...@zewt.org
<mailto:gl...@zewt.org>> wrote:
FYI, I don't think this is clear for File from the spec.
It's even more important if File objects are stored in
History or IndexedDB; that it should be a *shallow* copy,
with enough information stored to invalidate it if the
underlying file changes, doesn't seem to be specified.
(As far as I know, nobody implements that yet; being able
to eg. retain open files in History states would be
extremely useful.
Gecko nightlies are capable of storing File objects in
IndexedDB, We are doing "deep" copies (what is retrieved from
the database is always a copy of the file as it was when it
was placed in the database).
Oh I'm glad to see this one! Is it Blob and File that can be put
into IDB? How do I create a new File (with a name field) from a Blob?
Charles: see the thread on making Blobs constructable -- follow
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0439.html
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0918.html
Seems like the consensus was to stay away from Blob to File methods.
FileEntry and [a download] being the heirs apparent.
The File API specification should do a better job describing what
happens to a File if the underlying resource changes. We use the word
immutable, but I think we have to make this substantially clearer.
My take on a File object that's been modified is that the file no longer
exists.
"User agents MUST process reads on files that no longer exist at the
time of read as errors"
"A file may change on disk since the original file selection, thus
resulting in an invalid read."
FileList is live; and UAs can go several ways with it. They can return
new File objects, with updated information (yes, please); or they can
otherwise cut out modified files or later, throw the security error as
specified: "Post-selection file modifications occur when a file changes
on disk after it has been selected. In such cases, user agents MAY throw
a SecurityError for synchronous read methods, or return a SecurityError
DOMError for asynchronous reads.".
It's a consideration, anyway. I don't think people expect that, if they
select a file for uploading, then modify the file before hitting submit,
that they'll no longer upload a file. It would, I suppose, "disappear"
from the Chosen file option.
There is a significant difference between selecting files and mounting a
directory for persistent access. In one of them, the files are listed
and new files are not added. So I may select a single file, and it'll
show up in input type=file, or I'll see a count of the files I selected.
With mounting a directory, I'm given continued access to poll for new
files. I think that's enough of a distinction to keep the current
behavior of allowing persistent access to selected files via FileList.
If it's not enough of a distinction, I'd like more semantics added to
requestFileSystem to re-establish the persistent selection of files.
-Charles
