- From: Jarred Nicholls <jarred@webkit.org>
- Date: Wed, 11 Apr 2012 21:21:55 -0400
- To: Kenneth Russell <kbr@google.com>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps <public-webapps@w3.org>
- Message-ID: <CANufG2MmMKcPBwK0G0rJFd+j4V=0vEvsTvYAH3Uc+16AbRLYWw@mail.gmail.com>
On Wed, Apr 11, 2012 at 5:54 PM, Kenneth Russell <kbr@google.com> wrote: > On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > On 4/11/12 5:41 PM, Kenneth Russell wrote: > >> > >> 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. > > > > > > I'm not sure what this means... > > What I mean is that if somehow a browser were on the receiving end of > one of these messages, the type of the incoming message should still > be "arraybuffer". > > > For XHR.send(), sending an ArrayBufferView should take the byte array > that > > the ArrayBufferView is mapping, and send that. It's possible to achieve > the > > same thing now with some hoop jumping involving a possible buffer copy; > I'm > > just saying we should remove the need for that hoop jumping. > > Agree that these should be the semantics. > > > I haven't looked at WebSocket in enough detail to comment intelligently > on > > it. > > I haven't really either, but if there were some peer-to-peer support, > then the receiving peer should still get an ArrayBuffer even if the > sender sent an ArrayBufferView. > Yes, this is the only approach that would make sense to me. The receiver is just getting a dump of bytes and can consume them however it sees fit. The view makes no difference here. > > -Ken > >
Received on Thursday, 12 April 2012 01:22:44 UTC