On 12/27/2010 3:29 PM, Glenn Maynard wrote:
On Mon, Dec 27, 2010 at 5:31 PM, Charles Pritchard<[email protected]> wrote:
Nothing in Canvas is current asynchronous. Nor is there precedent, beyond
string serialization, in the File API, for compression/checksum/stream
processing.
Not sure what you mean by the latter. Everything in both the File API
and the filesystem API has an async interface.
With async, I'm referring to Canvas.
With the File API, readAsXXX is as far as things have gotten.
There's no precedent, yet, for deflate compression, sha1/md5 checksum, etc.
Synchronous getBlob support would take minimal time, in code bases and specs
processes,
and has the very immediate benefit of ridding the DOM of nasty data uri
strings.
A synchronous API doesn't need to wait for an asynchronous one (no pun
intended); most async interfaces have synchronous counterparts. But,
please keep the async case in mind. Seeing async compression
dismissed out-of-hand in
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024691.html
was a bit worrisome.
You may not want to build an entire Blob in memory: most compression
works on a sliding window.
Using an ArrayBuffer, with onprogress events would be more flexible (and
verbose)
than using a getAsyncBlob method.
ArrayBuffer has a similar use for XHR responses in memory limited areas.
responseBlob is still being hashed out, it seems.
