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

Re: File modification

From: Arun Ranganathan <aranganathan@mozilla.com>
Date: Thu, 12 Jan 2012 12:53:58 -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: <33c68920-5f06-4443-b91b-f3e9fd21025e@zimbra1.shared.sjc1.mozilla.com>
On Jan 12, 2012, at 6:58 AM, Kyle Huey < me@kylehuey.com > wrote: 

> > On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard < glenn@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* 
Received on Thursday, 12 January 2012 20:55:09 GMT

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