W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

[FileAPI] FileReader

From: Anne van Kesteren <annevk@opera.com>
Date: Tue, 10 Nov 2009 17:56:11 +0100
To: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.u26unx1x64w2qv@annevk-t60>
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
Received on Tuesday, 10 November 2009 16:56:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC