Re: [XHR2] responseType and response properties

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.

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

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.

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

/ Jonas

Received on Monday, 23 May 2011 23:28:46 UTC