Perhaps we should think of a better scheme to export data than toFoo().
Maybe toData('url'), toData('arraybuffer') toData('blob') or perhaps
toData(URL), toData(ArrayBuffer) or toData(Blob). I tend to think that if
you're starting to write toA, toB, toC, toX methods on an object, you've
not thought this really trough what's a parameter, and what's a method.On Wed, Jan 16, 2013 at 4:26 PM, Glenn Maynard <[email protected]> wrote: > On Wed, Jan 16, 2013 at 6:29 AM, Kyle Huey <[email protected]> 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 > >
