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 Feb 2011 14:56:13 -0800
Message-ID: <4D4B328D.5000107@jumis.com>
To: Anne van Kesteren <annevk@opera.com>
CC: WebApps WG <public-webapps@w3.org>, ATSUSHI TAKAYAMA <taka.atsushi@googlemail.com>
On 2/1/2011 6:05 AM, Anne van Kesteren wrote:
> On Tue, 01 Feb 2011 14:58:02 +0100, ATSUSHI TAKAYAMA 
> <taka.atsushi@googlemail.com> wrote:
>> (I didn't send the previous mail to the list, so sending again)
>>> I hope we can actually just do this by exposing "blob" earlier than 
>>> DONE in due course. With the Blob object on disk growing over time. 
>>> If you really just want to stream data I think we should use 
>>> EventSource for that.
>>
>> IMHO, EventSource is too cumbersome to handle binaries as you have to
>> special-case both CR and LF, and CRLF sequence.
>
> That it does not deal with raw octet-data now does not mean it will 
> not in the future.

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.

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.

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.

-Charles
Received on Thursday, 3 February 2011 22:56:43 GMT

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