On Wed, 11 Apr 2012 22:06:07 +0200, Glenn Maynard gl...@zewt.org wrote:
I might argue that we shouldn't have ArrayBuffer entry points at all;
just ArrayBufferView. It's trivial to create a view on the whole of an
ArrayBuffer, and this is leading towards us having two separate entry
points for
On Wed, 11 Apr 2012, Glenn Maynard wrote:
That's not really what happens, though. WebSocket gives you an ArrayBuffer
if the source is an ArrayBuffer, and a Blob if the source was a Blob
No, at the protocol level they are indistinguishable, and at the API
level the receiver decides which to
On Thu, Apr 12, 2012 at 1:34 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 11 Apr 2012, Glenn Maynard wrote:
That's not really what happens, though. WebSocket gives you an
ArrayBuffer
if the source is an ArrayBuffer, and a Blob if the source was a Blob
No, at the protocol level they are
Seems like right now passing a typed array to send() requires a bit of
extra hoop-jumping to pass the .buffer instead, right? Is that desirable?
-Boris
Yes; .buffer has stable semantics across many apis.
It does feel awkward when first using it, but the design makes sense after some
experience.
On Apr 11, 2012, at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Seems like right now passing a typed array to send() requires a bit of extra
On 4/11/12 2:53 PM, Charles Pritchard wrote:
Yes; .buffer has stable semantics across many apis.
Like what?
It does feel awkward when first using it, but the design makes sense after some
experience.
My point is that we can have overloads taking both ArrayBuffer and
ArrayBufferView. Is
On Wed, Apr 11, 2012 at 12:04 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Seems like right now passing a typed array to send() requires a bit of
extra hoop-jumping to pass the .buffer instead, right? Is that desirable?
It's a bit worse than that, actually: if you want to send only part of a
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
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*
On 4/11/12 4:40 PM, Charles Pritchard wrote:
That argues for the removal of the ArrayBuffer overload, indeed, and
just leaving the ArrayBufferView version.
I've got no idea where TC39 is taking things.
ArrayBuffer and ArrayBufferView and such are not specced in TC39 at the
moment, and I'm
On 4/11/2012 1:49 PM, Boris Zbarsky wrote:
On 4/11/12 4:40 PM, Charles Pritchard wrote:
That argues for the removal of the ArrayBuffer overload, indeed, and
just leaving the ArrayBufferView version.
I've got no idea where TC39 is taking things.
ArrayBuffer and ArrayBufferView and such are
On 4/11/12 5:04 PM, Charles Pritchard wrote:
When/if we start using the Binary Data instead of re-purposing typed
arrays.
Then we'll need to add more send() overloads, probably. What those
overloads will be, exactly, depends on the final state of the Binary
Data spec. I don't see the
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*
On 4/11/12 5:28 PM, Charles Pritchard wrote:
Adding .send(ArrayBufferView) doesn't seem like it'd hurt anything; it
would help in the case of subarray.
OK, we agree that far. ;)
Removing .send(ArrayBuffer) would hurt things.
That seems plausible. I'm more interested in the addition than
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarsky bzbar...@mit.edu wrote:
Seems like right now passing a typed array to send() requires a bit of extra
hoop-jumping to pass the .buffer instead, right? Is that desirable?
It may be convenient to add an overload to send() (presumably on both
XHR and
On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarskybzbar...@mit.edu wrote:
Seems like right now passing a typed array to send() requires a bit of extra
hoop-jumping to pass the .buffer instead, right? Is that desirable?
It may be convenient to add
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...
For
On Wed, Apr 11, 2012 at 2:47 PM, Charles Pritchard ch...@jumis.com wrote:
On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarskybzbar...@mit.edu wrote:
Seems like right now passing a typed array to send() requires a bit of
extra
hoop-jumping to
On 4/11/2012 2:50 PM, Boris Zbarsky wrote:
On 4/11/12 5:47 PM, Charles Pritchard wrote:
On 4/11/2012 2:41 PM, Kenneth Russell wrote:
On Wed, Apr 11, 2012 at 10:04 AM, Boris Zbarskybzbar...@mit.edu
wrote:
Seems like right now passing a typed array to send() requires a bit
of extra
On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky bzbar...@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
On Wed, Apr 11, 2012 at 7:19 PM, Kenneth Russell k...@google.com wrote:
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
On 4/11/12 5:54 PM, Charles Pritchard wrote:
Note that those have different performance characteristics, too; the
latter involves a buffer copy.
Are we stuck with a buffer copy (or copy on write) mechanism anyway?
Yes-ish; the question is how many copies there are.
What is the spec on
On 4/11/12 5:54 PM, Kenneth Russell wrote:
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.
On Wed, Apr 11, 2012 at 5:54 PM, Kenneth Russell k...@google.com wrote:
On Wed, Apr 11, 2012 at 2:48 PM, Boris Zbarsky bzbar...@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
On Wed, Apr 11, 2012 at 8:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 4/11/12 5:54 PM, Charles Pritchard wrote:
Note that those have different performance characteristics, too; the
latter involves a buffer copy.
Are we stuck with a buffer copy (or copy on write) mechanism anyway?
25 matches
Mail list logo
