- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 11 Apr 2012 14:28:41 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- CC: Glenn Maynard <glenn@zewt.org>, public-webapps <public-webapps@w3.org>
On 4/11/2012 1:16 PM, Boris Zbarsky wrote: > On 4/11/12 4:06 PM, Glenn Maynard wrote: >> It's a bit worse than that, actually: if you want to send only part of a >> buffer, you have to create a whole new ArrayBuffer and copy the data >> over. If you just pass "view.buffer", you'll send the *whole* >> underlying buffer, not just the slice represented by the view. > > Oh, that's just broken. > > That argues for the removal of the ArrayBuffer overload, indeed, and > just leaving the ArrayBufferView version. > Adding .send(ArrayBufferView) doesn't seem like it'd hurt anything; it would help in the case of subarray. Removing .send(ArrayBuffer) would hurt things. I'd imagine that we saw send(ArrayBuffer) first because that's just how the semantics for ArrayBuffer have been used. It may cut down on constructors/header code within cpp implementations. As an author, I'm going to be stuck to .send(ArrayBuffer) for awhile, given the distance between this proposal and pick-up by MS and Apple. Again, if there's anything happening with TC39 that would make .send(BinaryData) available, I'm up for waiting on it, instead of jumping in early with ArrayBufferView. -Charles
Received on Wednesday, 11 April 2012 21:29:02 UTC