Re: Files on IndexedDB

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 <> 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]
>> <>
>> [2]
>> <>
>> [3] <>
>> On 5/30/13 5:24 AM, ext 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.

Received on Wednesday, 12 June 2013 00:51:29 UTC