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

On Wed, Apr 11, 2012 at 3:40 PM, Charles Pritchard <chuck@jumis.com> wrote:

>  I know you've been circling this issue for awhile, so I'll put it out
> there again: yes, using typed arrays is difficult.
>

Typed arrays have a few gotchas, and design decisions that I disagree with,
but I wouldn't call them difficult.


On Wed, Apr 11, 2012 at 4:41 PM, Kenneth Russell <kbr@google.com> wrote:

> ArrayBufferView implies knowledge of the type of data being pointed to.


Not *strictly*.  If you don't care about the type of the underlying data,
then you can simply use Int8Array to represent it.  This is the case with
XHR, where you're just sending the memory buffer verbatim.

In principle, we could have "UntypedView" or something to create a view on
ArrayBuffer without implying anything about the type, but I don't think
that really wins us anything useful.

The reason XHR, WebSocket and other APIs refer only to ArrayBuffer is
> probably to insulate them from changes in the typed array
> specification.


I suspect this is actually just an oversight.  (Anne?)


> It seems that there is general agreement that the
> ArrayBuffer concept, of a completely opaque in-memory data container,
> is useful.


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

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

I've mentioned some of my issues with it, but it's already implemented and
used in the wild, so there won't be any fundamental (incompatible)
changes.  So, there's no particular reason to avoid supporting views.

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

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

-- 
Glenn Maynard