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

Re: [FileAPI] FileReader

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 10 Nov 2009 09:39:57 -0800
Message-ID: <63df84f0911100939v4df7a113oacb2dd2879931a99@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>
On Tue, Nov 10, 2009 at 8:56 AM, Anne van Kesteren <annevk@opera.com> wrote:
> 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?

Either works. I was thinking the latter.

> 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'd rather be consistent with XHR here. I think the API actually make
more sense for FileReader than it does for XHR since in most cases
with file reader I think people will not care about progress events
given how fast a file typically loads. So in most cases you'd just
register a "load" (or "loadend") listener and get the data there.

I do think having a "streaming" mode for both XHR and FileReader makes
sense, but I think that should be a separate mode. Either activated
using a constructor argument, or using a property (similar to
.withCredentials).

I don't really see the advantage of making the reader take the
Blob/File as a constructor argument. That looses the ability to reuse
the reader to read multiple files (not a big deal), and makes it
different from XHR (bigger deal) for seemingly no reason.

> I also still think we should not introduce getAsDataURL() (there is
> File.urn/URL) and getAsBinaryString() (temporary hack).

We had the discussion about dataURLs before and I still think there
are good use cases. Such as creating a HTML editor with inline images
and then sending that over the wire or allowing the user to save it as
a single file.

I agree that getAsBinaryString is somewhat of a hack, however I'm
reluctant to remove it until ByteArray (or whatever it will be called)
has actually been defined.

/ Jonas
Received on Tuesday, 10 November 2009 17:40:57 GMT

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