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

On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard <glenn@zewt.org> wrote:
> (I don't think there's any particular reason for ArrayBuffer to be opaque.
> It would have been nice if ArrayBuffer acted like an Int8Array, so you can
> access the contents as an array of bytes without an extra step.)

That's the way Java's New I/O API worked and it caused asymmetries in
the API. I believe it was Chris Marrin who originally proposed
factoring out the storage into ArrayBuffer and that has worked out
very nicely. For example, ArrayBuffer is the only Transferable
interface in the spec, and all of the view types are equal peers in
the spec.

> It sounds like you're referring to structured clone here, rather than XHR?
> I think that you should be able to structured clone a view, and the result
> should be the same view type, attached to a newly-created ArrayBuffer.  If a
> structured clone operation sends multiple views that are from the same
> ArrayBuffer, it also seems like the result should be views on the same new
> ArrayBuffer.

I'm essentially referring to a hypothetical use case of peer-to-peer
communication over WebSockets. My point is only that the incoming
binary data type should continue to be "arraybuffer" in both XHR and
WebSockets. If one end of a WebSocket sent an ArrayBufferView, the
other end should still receive an ArrayBuffer.

Regarding structured clone, it works in exactly the way you state
above. I'm not proposing any changes to those semantics.

>  (I'm not sure about the details, though, eg. what happens if
> you have a 10 MB ArrayBuffer, and you send two Int8Arrays which are views on
> the first and last bytes?  Is the new ArrayBuffer "packed", with the unused
> parts of the array removed?  This would need some thought.)

No, compacting the ArrayBuffer behind the scenes could break
applications. The new ArrayBuffer would need to contain all of the
original data. For highest performance the application could put the
ArrayBuffer into the Transferable array.

-Ken

Received on Thursday, 12 April 2012 00:20:12 UTC