Re: Files on IndexedDB

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 18:24:41 UTC