Hi - your comment is considered a "Last Call comment" and it was
included in the LC's comment tracking document [1].
In [2], Joshua proposed this comment be addressed/resolved as a feature
request and as such, it was added to the IDB feature request list [3].
For the purposes of tracking your comment, please indicate if this
resolution is acceptable or not.
-Thanks, ArtB
[1]
<https://dvcs.w3.org/hg/IndexedDB/raw-file/default/Comments-16-May-2013-LCWD.html>
[2]
<http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0817.html>
[3] <http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures>
On 5/30/13 5:24 AM, ext [email protected] 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.
File and FileList objects are only available from Input tags (at this
moment you can't be able to create them by hand, and also can't be
downloaded, only Blob objects), so they exists on the user hard disk,
so it's not necesary to make a duplicate and waste space. It would
make sense to store a copy inside IndexedDB when you want to store it,
but if you want to store only some metadata for the File object (for
example a hash of the file, or a flag for "already viewed" chapters on
a local hard disk stored serie) making a copy is useless.
Also, although is being currently discused, FileList objects are
suposed to be "live" objects showing the current status of a directory
each time is readed (both added, updated and removed File objects),
and File objects should work the same, working mainly as references to
the hard disk status that would not be the actual one if they are
stored duplicates on the database (they will show the status when the
File / FileList was stored), and specially when the IndexedDB is
accessed between reloads.
On the other hand, Blob objects can be created and downloaded, so it
makes sense to store duplicates of data that's currently on RAM and
would disappear after a page reload, in the same way you save your
work before closing an application.
So my proposition is about to allow the File and FileList objects
being stored as actual references to the original hard disk File and
FileList objects instead of data duplicates, and only store really
inside IndexedDB data from Blob objects. This way would allow to store
references to opened File and FileList objects between reloads of the
page without requiring to the user to re-select them and process them
again as new, while allowing to store data (also File objects) inside
IndexedDB in the form of Blob objects.
