Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On 10/26/10 7:55 PM, Chris Marrin wrote:
>> Hmm...  But will people still be accessing .responseText on those?  And if so, wouldn't they be broken by the proposals so far in this thread?
>
> Probably not. But you'd either need to convert data from the raw form to the desired form on every call to responseXXX()

Just for responseText, right?  For responseArrayBuffer you just make a 
copy (possibly with a copy-on-write mechanism) and hand it back. 
There's no conversion.

And again, for the specific case of large datasets you cited you're not 
expecting this to be an issue.  So when _is_ this an issue?

> or store 2 copies of the data (the raw form and the most recently converted form).

Or a mix, as I said earlier in this thread (store the converted form for 
some time, then drop it, e.g.).

> I believe the proposals are trying to get rid of the need for the performance or memory hit.

Yes, I understand the goal of the proposals.  I just think they're 
excluding valid use cases in the process.

>> This doesn't seem to allow deciding on the "type" based on the content type returned by the server....
>
> Is that a requirement? I don't understand XHR very well, but isn't there a way to get the header, determine the desired type and then do another get for the data?

You can do another GET... but there's no guarantee that you'll get what 
you want.  And if the data is large this can be expensive, on both the 
server and the client.

And you _certainly_ can't do another POST.

> If this will be part of XMLHttpRequest then we need to support the legacy API. If this is part of a new XMLHttpRequest2 object or something, then we don't I guess.

Ah, ok.

-Boris

Received on Wednesday, 27 October 2010 00:55:02 UTC