On Wed, Oct 27, 2010 at 12:12 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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
>
So, it sounds like we just need to present you with some concrete examples
of XHRs being used to fetch large responses as Text or XML, and then you
will be convinced?
I wrote a web app that processes a subversion log using responseXML. Does
that count? (The subversion log is pretty big. 45MB for all of WebKit.)
-Darin