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

Re: File modification

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Fri, 13 Jan 2012 11:13:18 -0800 (PST)
To: Charles Pritchard <chuck@jumis.com>
Cc: Glenn Maynard <glenn@zewt.org>, Jonas Sicking <jonas@sicking.cc>, Charles Pritchard <chuck@visc.us>, public-webapps@w3.org, Eric U <ericu@google.com>, Kyle Huey <me@kylehuey.com>
Message-ID: <b595c1f8-dd47-4552-8902-f99613dc2e8b@zimbra1.shared.sjc1.mozilla.com>
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 


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 19:13:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:30 UTC