W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: File API: reading a Blob

From: Takeshi Yoshino <tyoshino@google.com>
Date: Mon, 8 Sep 2014 13:58:23 +0900
Message-ID: <CAH9hSJY=NUgCs3j1=Z38nwP=oUZikT=f8W7Z6QGaAg1WHzX2yQ@mail.gmail.com>
To: Aymeric Vitte <vitteaymeric@gmail.com>
Cc: Anne van Kesteren <annevk@annevk.nl>, Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>, Kyle Huey <me@kylehuey.com>, Joshua Bell <jsbell@google.com>
On Thu, Sep 4, 2014 at 7:02 AM, Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

> The fact is that most of the W3C groups impacted by streams (File,
> indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream,
> etc, I must forget a lot here) seem not to care a lot about it and maybe
> just expect streams to land in the right place in the APIs when they are
> available, by some unknown magic.
>
> I still think that the effort should start from now for all the APIs (as
> well as the implementation inside browsers, which apparently has started
> for Chrome, but Chrome was supposed to have started some implementation of
> the previous Streams APIs, so it's not very clear), and that it should be
> very clearly synchronized, disregarding vague assumptions from the groups
> about low/high level and Vx releases, eluding the issue.


Chrome has an experimental implementation [1] of the new Streams API [2]
integrated with XHR [3] behind a flag.

We receive data from the browser process over IPC (both network and blob
case). The size of data chunks and arrival timing depend on various
factors. The received chunks are passed to the XMLHttpRequest class on the
same thread as JavaScript runs. We create a new instance of ReadableStream
[4] on arrival of the first chunk. On every chunk arrival, we create an
ArrayBuffer from the chunk and then call [[enqueue]](chunk) [5] equivalent
C++ function to put it into the ReadableStream.

The ReadableStream is available from the "response" attribute in the
LOADING and DONE state (if no error). The chunks pushed to the
ReadableStream become available for read immediately.

Any problem occurs while loading data from network/blob, we call
[[error]](e) [6] equivalent C++ function with an exception as defined in
the XHR spec for sync XHR.

Currently, XMLHttpRequest doesn't exert any back pressure. We plan to do
something not to read too much data from disk/network. It might be worth
specifying something about the flow control in the abstract read from
blob/network operation at standard level.

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/xmlhttprequest/response-stream.html
[2] https://github.com/whatwg/streams
<https://github.com/whatwg/streams#readablestream>
[3] https://github.com/tyoshino/streams_integration/
[4] https://github.com/whatwg/streams#readablestream
[5] https://github.com/whatwg/streams#enqueuechunk
[6] https://github.com/whatwg/streams#errore
Received on Monday, 8 September 2014 04:59:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC