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?
