On Wed, Mar 16, 2011 at 4:59 PM, Charles Pritchard <ch...@jumis.com> wrote: > On 3/16/2011 4:34 PM, Eric Uhrhane wrote: >> >> On Thu, Feb 10, 2011 at 4:55 PM, Eric Uhrhane<er...@google.com> wrote: >>> >>> On Thu, Feb 10, 2011 at 3:27 PM, Ian Hickson<i...@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?
Not that I recall. It's not a great match, really, because the data returned from a Canvas doesn't have a name, a parent directory, etc. If you just need an asynchronous way to get a File or Blob from a Canvas, just make Canvas.toFile take a callback.
