Re: File modification

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" <aranganathan@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*
>