- From: Kenneth Russell <kbr@google.com>
- Date: Wed, 11 Apr 2012 14:41:12 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps <public-webapps@w3.org>
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > Seems like right now passing a typed array to send() requires a bit of extra > hoop-jumping to pass the .buffer instead, right? Is that desirable? It may be convenient to add an overload to send() (presumably on both XHR and WebSocket? Any others?) accepting ArrayBufferView. As pointed out elsewhere in this thread, ArrayBufferViews are a lightweight mechanism to refer to a sub-portion of an ArrayBuffer. All of the WebGL APIs which accept ArrayBuffer also accept ArrayBufferView, though the converse is not true. ArrayBufferView implies knowledge of the type of data being pointed to. In WebGL, some APIs accept only certain subclasses of ArrayBufferView, depending on other arguments to the function (readPixels, texImage2D, etc.). The reason XHR, WebSocket and other APIs refer only to ArrayBuffer is probably to insulate them from changes in the typed array specification. It seems that there is general agreement that the ArrayBuffer concept, of a completely opaque in-memory data container, is useful. It's clear that there is some disagreement with some of the other design decisions of the typed array specification, which might motivate leaving only the ArrayBuffer overload for the time being. Sending an ArrayBufferView would still have to use "arraybuffer" as the type of data. I don't think it would be a good idea to try to instantiate the same subclass of ArrayBufferView on the receiving side. -Ken
Received on Wednesday, 11 April 2012 21:42:01 UTC