On 1/13/12 11:13 AM, Arun Ranganathan wrote:
On 1/12/12 12:53 PM, Arun Ranganathan wrote:
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.
Well, the consensus was to introduce a constructor to Blob, which I'm
about to do :)
Sorry, I misread that thread; and misremembered it. I saw it as
appending multiple strings.
I'm happy to see the Blob constructor happening!
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."
Just to be clear, "disappearing" a file from FileList might is the
same as|
item(index)
|returning null for the the index'th item. Maybe this should be
enforced as well for any kind of modification? This isn't what Fx
does today.
I'm fine with that being the defined behavior for FileList when
implementations have elected to remove modified files.
It's still optional: implementations MAY remove modified files from the
FileList, those that do MUST return null for the index'th item.
I'm hoping they don't go down that route. It may mean a disconnect
between the results of submitting a post
and the files available to the scripting environment.
Again, I don't imagine that <input type="file"> and a subsequent
.submit() would result in an empty POST when the user modifies the
underlying file.
Though it should do so if the user deletes or renames the underlying
file. I suppose things could get nasty, though, if the user modifies the
file while the post is happening. I don't want to think about those kind
of race conditions. Hopefully the UA can put a temporary write lock on
those files.
Well... I'm satisfied on this topic. I think we've incrementally
improved what the File API will specify.
-Charles
