Re: File API: reading a Blob

Does your experimentation pipe the XHR stream to MSE? Obviously that 
should be the target for yt, this would be a first real application of 
the Streams API.

Because the Streams API does not define how to apply back pressure to 
XHR, but does define how to apply back pressure between XHR and MSE.

Probably the spec should handle on a per case basis what should be the 
behavior in term of back pressure for things coming from outside of the 
browser (xhr, websockets, webrtc, etc , not specified as far as I know) 
and for things going on inside the browser (already specified)

Le 08/09/2014 06:58, Takeshi Yoshino a écrit :
> On Thu, Sep 4, 2014 at 7:02 AM, Aymeric Vitte <vitteaymeric@gmail.com 
> <mailto: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

-- 
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms