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

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
>
>
>
>