Re: File API: reading a Blob

+Aaron

On Thu, Sep 11, 2014 at 6:48 PM, Aymeric Vitte <vitteaymeric@gmail.com>
wrote:

>  But I suppose that should be one of the first use case for Google to
> introduce streams with MSE, no?
>
>
We're (and will) sharing updates about Streams with MSE folk (Aaron). MSE
side would be updated once Streams API becomes stable enough for them to
start revising.


> To be more clear about what I mean by "back pressure for things coming
> from outside of the browser":
>
> - XHR: the Streams API should define how xhr gets chunks using Range
> according to the flow and adapt accordingly transparently for the users
>
>
We're not thinking of involving multiple HTTP transactions for one send().
That's beyond current XHR semantics. I think even if we implement that kind
of feature, we should add it as a new mode or API, not as a new
responseType.

What we plan to do is connecting the Streams API's back pressure with TCP
congestion control. Since socket API doesn't expose much details to user,
we'll just control frequency and the size of buffer to pass to read(2).


> - WebSockets: use something like bufferedAmount but that can be notified
> to the users, so the users can adapt the flow, currently bufferedAmount is
> not extremely usefull since you might need to do some polling to check it.
>
>
For WebSockets, there're two approaches of Streams integration.
ReadableStream of messages or ReadableStream of ArrayBuffer representing
chunks of the payload of a message.

We need to discuss that first.


>
> Le 11/09/2014 08:36, Takeshi Yoshino a écrit :
>
>  On Thu, Sep 11, 2014 at 8:47 AM, Aymeric Vitte <vitteaymeric@gmail.com>
> wrote:
>
>>  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.
>>
>
>  It's not yet updated to use the new Streams. Here's our layout test for
> MSE. responseType = 'legacystream' makes the XHR return the old version of
> the stream.
>
>
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/http/tests/media/media-source/mediasource-append-legacystream.html&q=createMediaXHR&sq=package:chromium&type=cs&l=12
>
>  You can find the following call in the file.
>
>  sourceBuffer.appendStream(xhr.response);
>
>
>>
>> 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>
>> 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
>>
>>
>
> --
> 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
>
>