Re: Files on IndexedDB

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.

/ Jonas

On Tue, Jun 11, 2013 at 11:24 AM, Arthur Barstow <art.barstow@nokia.com> 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 piranna@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.
>>
>> 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 Tuesday, 11 June 2013 23:57:21 UTC