The design of the FileReader API is a bit awkward. It's sort of the
inverse of the XMLHttpRequest API (by having separate read methods rather
than separate response getters) though the moment we add support for octet
streams we get both? Or will the result attribute start to return
non-string values?
I have been thinking about alternatives, e.g. by letting the FileReader
constructor accept a Blob as argument, having the event objects carry the
data, but have not really gotten much further yet. I do think that letting
the events carry a pointer to the data is better. The only reason
XMLHttpRequest does not have that is historical. Most other APIs that
involve transmission of data do it that way (WebSocket / EventSource).
I also still think we should not introduce getAsDataURL() (there is
File.urn/URL) and getAsBinaryString() (temporary hack).
(There is also various issues with how the read methods are defined in
terms of event handling and task queues, but those can be resolved after
the general API is agreed upon I suppose.)
--
Anne van Kesteren
http://annevankesteren.nl/
