Re: [FileAPI] FileReader

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 UTC