Bug 17263 - Keep on having send(ArrayBuffer data) interface in addition to send(ArrayBufferView data)
Keep on having send(ArrayBuffer data) interface in addition to send(ArrayBuff...
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: WebSocket API (editor: Ian Hickson)
unspecified
PC All
: P2 normal
: ---
Assigned To: Ian 'Hixie' Hickson
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-31 05:59 UTC by Takashi Toyoshima
Modified: 2012-07-26 08:58 UTC (History)
12 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Takashi Toyoshima 2012-05-31 05:59:35 UTC
negative reason is just for compatibility.
But, sometimes JavaScript has an ArrayBuffer object without any ArrayBufferView.
E.g., obviously JavaScript has only ArrayBuffer object which are received via WebSocket API.
I think the old interface send(ArrayBuffer data) is worth to be held.
Comment 1 Anne 2012-05-31 10:14:36 UTC
The problem is that then you're exposing platform endianness.
Comment 2 Takashi Toyoshima 2012-05-31 12:41:13 UTC
If I understand correctly, a browser is not expected to convert ArrayBufferView to a binary frame in the network byte order or to transform into some platform independent structure. So there is no difference between ArrayBuffer and ArrayBufferView from the viewpoint of endian. I think major benefits to use ArrayBufferView is that we can send a part of ArrayBuffer without any extra copy. It is because subarray() can create a object which refer a part of the buffer with start and end offset information.

I could not find authoritative information how TypedArray handle endian. At least, DataView has interfaces which required explicit endian indication and its default behavior is big endian. But, in my environment TypedArray works as little endian. I guess TypedArray depends on platform endian type, but it's good for use cases of TypedArray.
Comment 3 Glenn Maynard 2012-05-31 16:24:42 UTC
(In reply to comment #0)
> negative reason is just for compatibility.
> But, sometimes JavaScript has an ArrayBuffer object without any
> ArrayBufferView.
> E.g., obviously JavaScript has only ArrayBuffer object which are received via
> WebSocket API.
> I think the old interface send(ArrayBuffer data) is worth to be held.

If it's genuinely needed for web compatibility, that's fine.

But if it's not, then it should be removed.  It's cheap and trivial to create an Int8Array view around the ArrayBuffer: "xhr.send(new Int8Array(array))".  It's not worth adding an ArrayBuffer overload to every API that accepts typed arrays, just to avoid 15 bytes of typing (especially for something that's being typed rather infrequently).

(In reply to comment #1)
> The problem is that then you're exposing platform endianness.

You can treat sending an ArrayBuffer as equivalent to creating an Int8Array and sending that.  The typed array spec has major bugs around endianness, but I don't think this would add to them.
Comment 4 Ian 'Hixie' Hickson 2012-05-31 17:34:02 UTC
I don't understand how sending an ArrayBuffer rather than an ArrayBufferView exposes endianness. Can you elaborate? The way I specced it, they should be exactly identical, since all the spec does is send the ArrayBuffer that the ArrayBufferView references (suitably cropped)...
Comment 5 Adrian Bateman [MSFT] 2012-05-31 21:18:16 UTC
As I mentioned at the WebApps F2F, Microsoft intends to continue supporting ArrayBuffer for these scenarios. It is too late in our cycle to change this now and we have content already created that relies on supporting ArrayBuffer. We're okay with the change to also support ArrayBufferView - that makes good sense.
Comment 6 Anne 2012-06-21 14:36:37 UTC
Not sure if my response is still wanted, but I'll defer to Glenn and note that we did remove it from other APIs such as XMLHttpRequest. We should have a somewhat consistent story.
Comment 7 Adrian Bateman [MSFT] 2012-06-21 15:09:25 UTC
We haven't (and won't) removed it from any APIs in IE. It was too late a change for us to consider and we have people building on these APIs. It doesn't seem harmful to allow both.
Comment 8 Ian 'Hixie' Hickson 2012-07-10 21:39:48 UTC
It's harmful just because it's extra API surface area.
Comment 9 Takashi Toyoshima 2012-07-13 04:30:20 UTC
We, WebKit, couldn't remove it for now.
If Ian removed it from the spec, we will try to abandon it.
But, we will remove it after statistics shows it being obsolete enough.
Comment 10 Yuta Kitamura 2012-07-13 04:35:48 UTC
WebKit project's consensus would be summarized as:
- We don't drop ArrayBuffer support immediately. We will show users a console warning to encourage migration.
- We will probably keep the ArrayBuffer support until its usage is proven to be reasonably low according to our usage metrics.
Comment 11 Edward O'Connor 2012-07-17 21:23:46 UTC
Yuta, I think it's premature to say that the WebKit project has consensus that we'll be able to drop using ArrayBuffers here (or in the other places we've added ArrayBufferView).
Comment 12 Adrian Bateman [MSFT] 2012-07-17 21:56:41 UTC
We have a significant enough amount of content using ArrayBuffer that it will be difficult for us to remove it and so not really worth the compatibility cost.
Comment 13 Glenn Maynard 2012-07-17 22:23:07 UTC
The ideal solution would be for ArrayBuffer and ArrayBufferView to share a base class, so there'd be no distinction for functions like this, and people wouldn't need to create a view over the whole buffer for functions that don't care about data types.  (Ideally, ArrayBuffer would simply implement Uint8Array.)

Unfortunately, the TypedArray Constructor(TypedArray array) and Constructor(ArrayBuffer buffer, ...) constructors get in the way of this, since unfortunately those functions do subtly but significantly different things (the former allocates new storage, the latter creates a view).  It's hard to fix this now without breakage: the TypedArray ctors should never allocate, and a deep copy should require a separate function call.

I mention this only in case somebody has any ideas for correcting this that I haven't thought of.  Maybe I'm overestimating the impact of changing TypedArray(TypedArray) to creating a shallow view (maybe this is rare in practice?), but I suspect not.
Comment 14 Ian 'Hixie' Hickson 2012-07-25 21:49:38 UTC
I've put this back since multiple browser vendors said they were going to implement it anyway. I recommend making sure that XHR implementations are following the XHR spec or else changing the XHR spec back as well.