W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: File API and Directory API feedback

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 16 Mar 2011 16:59:32 -0700
Message-ID: <4D814EE4.2020902@jumis.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT