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
