[whatwg] Binary Streaming with XHR

[Jussi Kalliokoski]

Good idea! I'm not attached to the semantics, only to the functionality.

Cheers,
Jussi

On Fri, Aug 24, 2012 at 3:46 PM, Simon Pieters <simonp at opera.com> wrote:

> 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 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
>