On 6/11/13 7:56 PM, ext Jonas Sicking wrote:
Hi Art,
Actually, the response in [2] says that we should clarify in the spec
that files, blobs and filelists are stored "by value" rather than "by
reference". This is not a normative change since the spec already
defines this behavior. However the behavior is defined somewhat
indirectly which means that it'd make sense to clarify it explicitly.
Hi Jonas - ok. Would you or one of the other Editors please propose text
to address this comment so piranna can review it (or check in fix and
then provide the URL of the changeset)?
-Thanks, Art
/ Jonas
On Tue, Jun 11, 2013 at 11:24 AM, Arthur Barstow <[email protected]> wrote:
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.
