- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Tue, 11 Jun 2013 14:24:15 -0400
- To: "piranna@gmail.com" <piranna@gmail.com>
- CC: public-webapps@w3.org
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