- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 11 Jun 2013 16:56:19 -0700
- To: Arthur Barstow <art.barstow@nokia.com>
- Cc: "piranna@gmail.com" <piranna@gmail.com>, Webapps WG <public-webapps@w3.org>
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