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