W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Darin Fisher <darin@chromium.org>
Date: Wed, 27 Oct 2010 00:24:32 -0700
Message-ID: <AANLkTinXQE4SMyS-DKYpsE7EfS8OEHiFqiqfg9_9guVg@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, Geoffrey Garen <ggaren@apple.com>, jorlow@google.com, jamesr@chromium.org
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
Received on Wednesday, 27 October 2010 07:25:07 GMT

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