On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard <gl...@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
