- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 16 Mar 2011 16:59:32 -0700
- To: Eric Uhrhane <ericu@google.com>
- CC: Ian Hickson <ian@hixie.ch>, public-webapps@w3.org
On 3/16/2011 4:34 PM, Eric Uhrhane wrote: > On Thu, Feb 10, 2011 at 4:55 PM, Eric Uhrhane<ericu@google.com> wrote: >> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson<ian@hixie.ch> wrote: >>> A couple of points I noticed while briefly perusing the File API specs: >>> >>> * Blob.size has no conformance criteria (no "must"s). It could return a >>> random number each time and that would be conforming. It seems like it >>> should have at least some constraint related to how a FileReader >>> interacts with the Blob. >>> >>> * Is Blob.size supposed to be synchronous? I'm looking into adding a way >>> to get a Blob from<canvas>, but trying to avoid the mistake I made with >>> toDataURL of having the data be synchronously available. That's fine with >>> Blob and FileReader, the data can be read async, but the browser won't >>> know the size of the file ahead of time, which means that I guess I should >>> have a callback to get the Blob? It seems sad that we need to be async >>> both in getting the Blob _and_ in getting the data from the Blob. >> Yes, Blob.size is synchronous. This came up the last time people >> discussed getting one from a canvas, and nobody had a good solution >> that I can recall. Seems like the qualities of the FileEntry interface. Returns a blob interface async, which can then be read async. canvas.toFileEntry().file( callback ) toFileEntry is synchronous, returning a generic fileentry object, file method is async, and can return a typed array or blob. Was there discussion on using FileEntry semantics?
Received on Thursday, 17 March 2011 00:00:07 UTC