Re: [XHR2] responseType and response properties

On Mon, May 23, 2011 at 4:27 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Mon, May 23, 2011 at 12:27 PM, Kenneth Russell <kbr@google.com> wrote:
>> On Sat, May 21, 2011 at 12:36 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> Hi All,
>>>
>>> Firefox 6 is going to add support for the the new responseType and
>>> response properties. We would have liked to release these as
>>> moz-prefixed properties, but it appears that webkit has already
>>> shipped them unprefixed, thus there's not much point in prefixing.
>>> Both because we likely can't fix bugs in them anyway, and because
>>> sites have already started depending on them.
>>>
>>> I'd really like to reiterate that we need to be careful about
>>> releasing newly minted APIs unprefixed. Even in the case where we here
>>> on the list agree on the desired behavior. The Blob.slice mess (which
>>> we fortunately managed to save last minute) is a good example of why
>>> we should give API time to mature before unprefixing.
>>>
>>> So in that spirit, I have a questions about the actual behavior of XHR.response:
>>>
>>> First, should it return a new ArrayBuffer every time the property is
>>> accessed (This is how the mozResponseArrayBuffer property in FF4
>>> behaves), or should it return the same buffer every time? Since
>>> arraybuffers are mutable, there's a risk that one consumer will modify
>>> the response such that all other consumers see a modified result. On
>>> the other hand creating a new buffer every time can be quite expensive
>>> (at least without complex/slow copy-on-write implementations). It also
>>> would result in the surprising property that xhr.response !=
>>> xhr.response.
>>>
>>> In FF6 we're aiming to return the same buffer every time. The
>>> other-consumers-will-see-a-modified-result behavior is unfortunate,
>>> but similar to how responseXML behaves and hasn't seemed to cause a
>>> problem there.
>>
>> I think there was some discussion on this list a while ago about the
>> semantics, and that the consensus at the time was that a copy was
>> needed to avoid the mutation problem you mention. I agree that the
>> copy is problematic and expensive.
>>
>> Some changes to the Typed Array spec are in progress, one of which is
>> the addition of a read-only ArrayBuffer. Once this is finalized in the
>> Typed Array spec and implemented in browsers, XHR could return a
>> read-only ArrayBuffer from .response. Any comments about this would be
>> welcome. The discussion has mostly been going on on the WebGL mailing
>> list: https://www.khronos.org/webgl/public-mailing-list/ .
>
> I'm not actually sure that returning a read-only ArrayBuffer is always
> advantageous. In the by far most common case, there is only one
> consumer of a specific XHR request. In such a situation modifying the
> response does not run the risk of confusing other consumers as there
> are none. So in that situation it would be wasteful to force the
> consumer to copy the data just to be able to modify it.

The question to ask is whether it's common for that consumer to modify
the result of the XHR. In all of the use cases I'm aware of, it's
usually processed (maybe manually decompressed), sliced up and/or
passed to some other API, but not actually modified in place.

> Additionally, returning a new ArrayBuffer, even if read-only, still
> creates the confusing situation where xhr.response != xhr.response.

If the ArrayBuffer were read-only then it would not be necessary to
return a new one each time .response were called.

> Finally, since webkit already has release XHR.response unprefixed,
> it's going to be hard to change its behavior, especially from
> read/write to read-only.

That's certainly possible. I don't know how widely used the
ArrayBuffer response type is or what the compatibility impact would
be. However, I've received some anecdotal feedback from colleagues
that they would welcome efficiency improvements in this area (assuming
that the current ArrayBuffer response were copied each time it was
fetched).

> However adding a readonly ArrayBuffer would allows us to do things
> like xhr.responseType = "readonly-arraybuffer" if we want to.

Agreed.

-Ken

Received on Monday, 23 May 2011 23:58:17 UTC