- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 16 Jan 2013 09:26:43 -0600
- To: Kyle Huey <me@kylehuey.com>
- Cc: Florian Bösch <pyalot@gmail.com>, Webapps WG <public-webapps@w3.org>
Received on Wednesday, 16 January 2013 15:27:10 UTC
On Wed, Jan 16, 2013 at 6:29 AM, Kyle Huey <me@kylehuey.com> wrote: > I don't think there's any reason we can't have toArrayBuffer as well. The > hard part from an implementation perspective is asynchronously encoding the > image, not what we stick it in. > No technical reason, but I'd avoid adding yet more paths to do the same thing unless there's a real gain. It'd be bad to head down the path of every single Blob-returning operation having an ArrayBuffer duplicate. In this particular case, he wants ArrayBuffers to put the data in a ZIP, which probably means he should be doing this from a worker anyway, to avoid doing a bunch of CRC calculations on the UI thread. In that case, the current API isn't even inconvenient, since once you post the Blob to the worker you can use FileReaderSync and not have an extra async operation to do. ("Pass an array of Blobs to a worker and get back a Blob of a ZIP" is a generally useful operation, so maybe he wouldn't even have to write this himself.) -- Glenn Maynard
Received on Wednesday, 16 January 2013 15:27:10 UTC