W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2013

Files on IndexedDB

From: <piranna@gmail.com>
Date: Thu, 30 May 2013 11:24:40 +0200
Message-ID: <CAKfGGh0ccTpdKc843+Abd+e3WAMKtaHTENn46B-aOY8resrJtg@mail.gmail.com>
To: public-webapps@w3.org
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.
Received on Thursday, 30 May 2013 09:25:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:18:49 UTC