- From: Kenneth Russell <kbr@google.com>
- Date: Mon, 23 May 2011 12:27:42 -0700
- 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 UTC