On 5/18/10 2:35 PM, Eric Uhrhane wrote:
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titov<dim...@chromium.org> wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are multiple hints that the blob should
be actually a 'file'. As we see Blob concept grows in popularity with such
specs as FileWriter that defines BlobBuilder. Other proposals include Image
Resizing that returns a Blob with a compressed image data. Can all types of
Blobs be 'read' using FileReader? If not, then it would be logical to only
accept File parameter. If any type of Blob can be read (as I think the
spirit of the spec assumes) then would it be less confusing to cange the
name to BlobReader?
I'd support that. I think we always want to allow reading of any type
of Blob--it's the interchange container--so calling it BlobReader
makes sense. Arun, how do you feel about that?
The FileReader object accepts File objects for DataURL-reads, and Blob
objects for binary string, text, and binary reads. I agree that having
a name like FileReader is generally a bit confusing, given that we do
allow Blobs to be read, including Blobs which aren't directly coined
from files. Blob itself isn't a great name, though it's a stand-in for
Binary Large Object.
Aside from the slight bikeshed-ish nature of this discussion, there are
implementations in circulation that already use the name FileReader
(e.g. Firefox 3.6.3). This doesn't mean I'm against changing it, but I
do wish the name change suggestion came earlier. Also, I'm keen that
the main object name addresses the initial use case -- reading file
objects. Perhaps in the future Blobs that are not files will be the
norm; maybe then, Blob APIs will evolve, including implementations with
ArrayBuffer and potential streaming use cases getting addressed better.
Perhaps it is late to have a name change, and we've added to
less-than-adequate naming on the Web (example: XMLHttpRequest).
Would FileWriter ever be used to write anything other than a File? I
think not, so it should probably stay as it is, despite the lack of
symmetry.
2. The FileReader.result is a string.
Actually, in my next draft, I will have FileReader.result be of type
'any' (WebILD's 'any') since it could also be an ArrayBuffer (using the
readAsBinary method, which will function like the other asynchrous read
methods, but read into ArrayBuffers across the ProgressEvent spectrum.
-- A*
