Re: [whatwg] Binary Streaming with XHR

On Fri, 24 Aug 2012 14:19:43 +0200, Jussi Kalliokoski  
<jussi.kalliokoski@gmail.com> wrote:

> On Fri, Aug 24, 2012 at 3:04 PM, Nils Dagsson Moskopp <
> nils@dieweltistgarnichtso.net> wrote:
>
>> Jussi Kalliokoski <jussi.kalliokoski@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  
> scheduled
> in the event loop, so unless the event loop is leaking, no race  
> conditions
> 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


-- 
Simon Pieters
Opera Software

Received on Friday, 24 August 2012 12:47:10 UTC