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