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
