- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 18 Jul 2011 14:52:15 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- CC: Adrian Bateman <adrianba@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Alfonso Martínez de Lizarrondo <amla70@gmail.com>, Webapps WG <public-webapps@w3.org>
On 7/18/2011 2:42 PM, Jonas Sicking wrote: >> > If there is an API that replies on File to >> > work correctly we think we should fix it to work with Blob. For example, FileReader is >> > really BlobReader and works fine with Blobs. To me, getFile() should be unnecessary and >> > the best fix for FormData is to just modify append for this situation. > While File and Blob are indeed very similar, they are also not the > same thing. I think being able to create files is an easy addition for > implementations, while it means not restricting getting Files from the > users file system. So if you have code that expects to read a File > from IndexedDB, the page can either populate that from the users > filesystem, or by generating the data manually and using > BlobBuilder.getFile. I'm very interested in this use case; I've been told that there may be issues with IndexedDB transaction constraints and FileReader/writer. Afaik, filewriter doesn't apply to blobs in this case. I don't know the consequences of callbacks to reader functions in the event loop, and whether that would end up "blocking" idb events. I'd imagine the blob is simply reset, and the stale reference remains until it can be cleaned up. I'm sorry I haven't found the original thread in which this issue is brought up... But again, I'm very interested in using IndexedDB with Blob, and being able to use createObjectUrl ( blob, fileName ). It's a -lot- easier than the FileSystem API. I'd reserve FileSystem writes to writing to a mounted directory, or other fs that the user browses outside of the app. For in-app storage of files, IDB is great [once blobs are implemented]. -Charles
Received on Monday, 18 July 2011 21:52:38 UTC