W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR2] responseType and response properties

From: Chris Rogers <crogers@google.com>
Date: Fri, 12 Aug 2011 17:43:39 -0700
Message-ID: <CA+EzO0kxJobhmizheC5O-5aQUdKYNjZ1ypgr4DmX=uYFDGnDeA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
Hi Jonas, sorry about the late reply - comments inline:

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

Sorry, about that.  I thought we had good agreement about the API.



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

This is exactly what WebKit is doing right now (returning null when the
loading is not yet complete).  After that point, every access to .response
returns the same ArrayBuffer object.

Chris
Received on Saturday, 13 August 2011 00:44:06 GMT

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