On 10/27/10 2:39 AM, Darin Fisher wrote:
I think XMLHttpRequest is trying to be too much of a kitchen-sink.
OK, something we agree on. ;)
Ideally, there'd be separate components that operate on an ArrayBuffer and produce a decoded string / XML document. Then, for the use case you are talking about, people could just ask for the response as an ArrayBuffer, inspect the response headers, and then optionally invoke a text decoder interface or a XML parser / DOM builder interface.
My worry is about fragility we introduce in situations where the person dispatching the XHR (library author or page author) and the person(s) reading the results (library/page authors) are not the same set. As long as the same object provides both views and the views are mutually exclusive, it's really easy for the dispatcher to change what they ask for and subtly break other consumers he doesn't even know about.
I'd be much happier with either separate objects that provide different views and can't be confused for each other or all the possible views being available on demand.
As for the performance discussion, we learned the hard way that it was valuable to only keep one copy of the XHR's data. There are some sites out there that load large documents. Sad, but true. Maybe James Robinson or someone else can dig up some examples.
Those would be helpful, yes.
I think we should try to design for a future where we don't have to compromise performance for capabilities.
If we can do that without compromising capabilities for performance too much, yes. Need to strike a balance.
If we keep the ArrayBuffer up front and only decode on demand, then we will be doing more work in the common case (in which someone only wants the responseText). That seems bad.
Well, sure. The question is how much more work it is, and how bad the other options are.
-Boris
