On Thu, May 30, 2013 at 4:24 AM, pira...@gmail.com <pira...@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
