W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: File modification

From: Glenn Maynard <glenn@zewt.org>
Date: Fri, 13 Jan 2012 17:36:21 -0500
Message-ID: <CABirCh-XZ_C7TKDmgMVA1GYj2Tq4ubt66iQOHU5pWWOva7u+9Q@mail.gmail.com>
To: Arun Ranganathan <aranganathan@mozilla.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Charles Pritchard <chuck@jumis.com>, public-webapps@w3.org, Kyle Huey <me@kylehuey.com>, Charles Pritchard <chuck@visc.us>, Eric U <ericu@google.com>
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*
>
Received on Friday, 13 January 2012 22:36:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:50 GMT