Re: Should send() be able to take an ArrayBufferView?

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