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

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

From: Michael Nordman <michaeln@google.com>
Date: Tue, 26 Oct 2010 16:49:35 -0700
Message-ID: <AANLkTimfAcWO4mw=j_NJJp4gCQvFHTg-FNUCOh=ocPrb@mail.gmail.com>
To: Chris Rogers <crogers@google.com>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, Darin Fisher <darin@google.com>, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, Geoffrey Garen <ggaren@apple.com>, jorlow@google.com
I'm in favor of adding the explicit asArrayBuffer attribute. Simple and
straight forward for both web developers and browser developers.


On Tue, Oct 26, 2010 at 3:39 PM, Chris Rogers <crogers@google.com> wrote:

>
>
> On Mon, Oct 25, 2010 at 3:33 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
>> On 10/25/10 6:21 PM, Chris Rogers wrote:
>>
>>>  People are concerned that it would require keeping two copies of the
>>> data around (raw bytes, and unicode text version) since it's unknown
>>> up-front whether "responseText", or "responseArrayBuffer" will be
>>> accessed.
>>>
>>
>> Note that Gecko does exactly that, and we've seen no problems with it...
>>  It's very rare to have really large XHR bodies, for what it's worth.
>
>
> Alexey and James Robinson from Google have experienced noticeable
> performance-related issues with keeping two copies.  Mobile devices are
> going to suffer especially from these problems.  Also, Chris Marrin points
> out that the payloads are likely to become MUCH larger when dealing with
> binary data.  It's simply wasteful to decode to text when it was clearly not
> intended to be used as text.  Performance isn't something we can just
> ignore.
>
> 2. Darin Fisher has suggested this approach: Add an "asArrayBuffer"
>>> attribute (similar to "asBlob") which *must* be set before sending the
>>> request if there will be a subsequent access of the
>>> "responseArrayBuffer" attribute.
>>>
>>
>> This make it impossible to decide whether to look at the text or the bytes
>> based on the content-type of the response (unless you allow setting the
>> attribute in some early-enough onStateChange callback _and_ libraries expose
>> XHRs in that early a state to consumers); having that ability seems like a
>> desirable feature.
>
>
> We already have an "asBlob" attribute which has the same issue.  Why is it
> so unreasonable to also have "asArrayBuffer".  If there's a different method
> we devise to also determine based on content-type when we receive the
> header, then that's fine too, but it doesn't seem to preclude the idea of
> having "asArrayBuffer".
>
>
>
>>
>>
>>  3. Get rid of the "asBlob" attribute and add a new "responseType"
>>> attribute which could be:
>>> "Text" <--- this is the default
>>> "XML"
>>> "Bytes"
>>> ... other types yet to be defined
>>>
>>
>> I'm not sure I follow this proposal.
>
>
> This was just an alternative to having "asBlob" and "asArrayBuffer"
> attributes, where instead there's a "responseType" attribute which can be
> set up front to one of several types.
>
>
>
>>
>>
>>  I can accept any of the proposed solutions and would like to hear what
>>> others think about these or other approaches.
>>>
>>
>> How about:
>>
>> 4)  Make things easy to use for authors; that means supporting
>> responseText and responseArrayBuffer, with access to both on the same XHR
>> object without weird restrictions and without clairvoyance required on the
>> part of the author.  If UAs feel that they don't want to keep both copies of
>> the data in memory on a permanent basis, they can optimize this by dropping
>> the responseText (on a timer or via a low-memory detection mechanism, or in
>> various other ways) and regenerating it from the raw bytes as needed.
>>
>> ?
>>
>
> I think we simply disagree about the performance issues involved.  Adding
> an "asArrayBuffer" or similar which can be set up-front does not hurt the
> current API which is used currently to receive text.  The normal API usage
> continues to behave as it does and would not break any existing libraries.
>  Any future libraries which will use the "responseArrayBuffer" attribute can
> easily be coded sensibly with "asArrayBuffer".  I think that in the vast
> majority of use cases, it *will* be known up-front what the type of the data
> is, so clairvoyance should not be an issue.  If we decide to also devise an
> approach which can make use of content-type information in the response,
> then that's fine too.
>
> Chris
>
>
>
>
Received on Tuesday, 26 October 2010 23:50:15 GMT

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