On Jan 12, 2012, at 6:58 AM, Kyle Huey < m...@kylehuey.com > wrote: > > On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard < gl...@zewt.org > > > wrote: >
> > > FYI, I don't think this is clear for File from the spec. It's > > > even > > > more important if File objects are stored in History or > > > IndexedDB; > > > that it should be a *shallow* copy, with enough information > > > stored > > > to invalidate it if the underlying file changes, doesn't seem to > > > be > > > specified. (As far as I know, nobody implements that yet; being > > > able > > > to eg. retain open files in History states would be extremely > > > useful. > > > > > Gecko nightlies are capable of storing File objects in IndexedDB, > > We > > are doing "deep" copies (what is retrieved from the database is > > always a copy of the file as it was when it was placed in the > > database). > > 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 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. -- A*
