W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [XHR2] ArrayBuffer support added

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 03 Mar 2011 16:45:08 -0800
Message-ID: <4D703614.1080807@jumis.com>
To: Anne van Kesteren <annevk@opera.com>
CC: WebApps WG <public-webapps@w3.org>, ATSUSHI TAKAYAMA <taka.atsushi@googlemail.com>
Following up on this older thread, Mozilla has added ArrayBuffer to 
their XHR object, though the documentation
is a little bare.

xhr.mozResponseArrayBuffer


On 2/4/2011 2:01 AM, Anne van Kesteren wrote:
> On Thu, 03 Feb 2011 23:56:13 +0100, Charles Pritchard 
> <chuck@jumis.com> wrote:
>> But in the present, we've got XMLHttpRequest, with CORS semantics, 
>> and all other manner of goodness.
>> EventSource seems to me, to have different use cases than the simpler 
>> XHR.
>
> Yes, it is meant for streaming. XMLHttpRequest isn't really. (And 
> EventSource will get CORS in due course.)
>
>
>> XHR is a pretty stable and well supported method, it seems that it'd 
>> be reasonably straightforward
>> to take the current good-will around that standard, and see if a 
>> second ArrayBuffer response type is warranted.
>
> I rather wait until all the new features are more widely adopted and 
> tested. Then we can see if they have been a success and if we need more.
>
>
>> One nice thing to come out of it, saving a large file to a disk via 
>> XHR and FileWriter would be made
>> much easier, with no need for temporary storage locations.
>>
>> Even with blob saved to disk, it'd take a lot of special case 
>> optimizations to make it efficient to copy
>> that Blob to a new file. It'd likely require a copy, instead of 
>> what's likely wanted: writing the file once.
>>
>> Developing this now could have a positive effect on a future 
>> EventSource standard.
>
>
Received on Friday, 4 March 2011 00:45:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT