W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [XHR2] responseType and response properties

From: Kenneth Russell <kbr@google.com>
Date: Mon, 23 May 2011 12:27:42 -0700
Message-ID: <BANLkTi=PJpCi_r=P=DRJuv_svqmvOSd2CQ@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
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/ .

-Ken

> Second, what should .response return before the download finishes? It
> would be nice if you could access partial results. However
> ArrayBuffers are fixed size and we won't know the total size until the
> whole download is finished. We could return a copy on each access, but
> again that would be somewhat expensive.
>
> For now we're going to return null during loading in FF6 when
> .responseType is set to "arraybuffer".
>
> / Jonas
>
>
Received on Monday, 23 May 2011 19:28:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:45 GMT