That would be bad; it would require null checks that people would forget to perform due to the rarity of the condition. Instead, it should return a File that fails when read attempts are made. (Of course, those errors are also rare, but it's at least not adding a *new* rare case.) On Jan 13, 2012 12:13 PM, "Arun Ranganathan" <aranganat...@mozilla.com> 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 :) > > > 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. > > -- A* >