[whatwg] Binary Streaming with XHR
simonp at opera.com
Fri Aug 24 05:46:29 PDT 2012
On Fri, 24 Aug 2012 14:19:43 +0200, Jussi Kalliokoski
<jussi.kalliokoski at gmail.com> wrote:
> On Fri, Aug 24, 2012 at 3:04 PM, Nils Dagsson Moskopp <
> nils at dieweltistgarnichtso.net> wrote:
>> Jussi Kalliokoski <jussi.kalliokoski at gmail.com> schrieb am Fri, 24 Aug
>> 2012 13:23:03 +0300:
>> > My first idea was that if you set a property called "chunkSize" on
>> > the XHR, it would start dispatching an event called "onchunk"
>> > whenever a chunk of that size has been loaded. That event would
>> > contain a property "chunk" that would be an array buffer containing
>> > that data. However, I'm having second thoughts on that approach as it
>> > is likely to produce a lot of garbage.
>> Can you elaborate on the nature of the lot of garbage you are expecting?
> Yes. The "chunk" property on the event would be a fresh ArrayBuffer, so
> unless it gets bound somewhere, it becomes garbage.
>> > Instead, my refined idea is that you'd set a "chunk" property on the
>> > XHR to an ArrayBuffer, and each time a chunk of the size of the
>> > "chunk" was ready, it would set the values of the "chunk" property
>> > accordingly and the "onchunk" event would be dispatched.
>> Maybe I have not understood it, but at first glance that approach seems
>> prone to race conditions. What happens if the next chunk is ready while
>> the “onchunk“ event for the last one has not been processed? Does the
>> “chunk” property get overwritten and the previous chunk's data is lost?
> This is not the case, let me clarify. Setting the chunk would be
> in the event loop, so unless the event loop is leaking, no race
> should happen.
Why not let the "chunk" event carry the ArrayBuffer in a .data property?
We could reuse the MessageEvent interface. This would be similar to how
messages are exposed in WebSocket.
> Cheers, Jussi
More information about the whatwg