Re: [XHR2] responseType and response properties

On Mon, May 23, 2011 at 4:57 PM, Kenneth Russell <kbr@google.com> wrote:
> 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).

I definitely don't think we should create a new ArrayBuffer every
time, no matter if we do read/write or read-only. That should remove
the efficiency concerns.

In fact, read/write would be strictly more efficient, though can
possibly be confusing. Though I'm not that worried about the confusion
part given that we haven't seen that for .responseXML.

/ Jonas

Received on Tuesday, 24 May 2011 01:07:30 UTC