Re: Files on IndexedDB

On Thu, May 30, 2013 at 4:24 AM, piranna@gmail.com <piranna@gmail.com>wrote:

> According to IndexedDB specification, File and Blob and FileList objects
> should be allowed to be stored inside IndexedDB doing a shallow copy. On
> Mozilla this is possible, although File and Blob objects are stored
> nativelly on a special place on the hard disk. Chrome is working on it at
> this moment. Problem is, seems they are being duplicated and a copy is
> stored instead of a reference to the original File. I think is not the
> correct way to do it... or at least not always.
>
The File API spec does allow browsers to store File by reference.

Note that there's one limitation to keep in mind.  File is meant to
represent a snapshot of the file at the time the user gave them to the
site, rather than the latest copy.  That is, if you store a File object in
something like IDB, and the user changes the file, the next time the site
is loaded it should either see a copy of the file as it was before, or get
an error, not see the user's changes.  This is meant as a security measure;
the idea is that a user giving a file to a site may not expect that he's
giving access to that file, and all future changes, for all time, and that
expecting users to manually revoke access to files somehow isn't reasonable.

This is represented by the "snapshot state" concept.
http://dev.w3.org/2006/webapi/FileAPI/#snapshot-state-section

The difficulty is that most filesystems don't support lightweight snapshots
of files.  Making a deep copy is one way to implement this, but painfully
inefficient for large files.  Storing the file's modification time with the
snapshot, and using it to determine if the file has been changed, should be
a close enough approximation to address the security concerns.  The spec
allows this (it leaves the specifics of the "state of the underlying
storage" as an implementation detail).

I don't know if there are other IndexedDB-specific issues (not familiar
with that API).

-- 
Glenn Maynard