[FileAPI] Immutability and structured clones of File

On Wed, Apr 13, 2011 at 1:01 AM, Darin Fisher <darin@chromium.org> wrote:

> Blobs are views on immutable data.  WebKit's implementation will reject
> reads on a Blob, which points to a file that has since been modified.  (This
> should be part of the spec if it is not.)
>

This suggests some answers to questions I've had:

http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0161.html(third
paragraph)
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-January/029821.html

What you describe reconciles File's immutability with the mutability of
actual files.  A File doesn't just represent a file; it represents a
particular version of a file, and if that version is no longer available
because the file was modified, then reading the File is an error, as if the
file had been deleted.

Is this described in the FileAPI spec?  The filesystem spec suggests it.
FileEntry.getFile() says "Returns a File that *represents the current state
of the file*".  I don't see it described in File itself[2], though.

It still leaves the question of whether you can store a File in persistent
storage (localStorage, IndexedDB, saved History sessions) by structured
clone.  This allows sites to access files they were previously granted
access to.  I suspected security concerns: users don't expect that when they
open a file on a site and close the tab, when they return it still has
access to the file.  This seems less of an issue if File is restricted to
the particular version of the file at the time it was selected.  (The site
could have read the file and stored its contents with localStorage or the
Filesystem API the first time around, anyway.)

It would be particularly useful for History states, so restoring a browser
session can restore open files along with everything else.  Chrome allows
storing File in History states, but unfortunately they're lost on session
restore.


[1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#methods-5
[2] http://dev.w3.org/2006/webapi/FileAPI/#file

-- 
Glenn Maynard