W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: ArrayBuffer and ByteArray questions

From: Kenneth Russell <kbr@google.com>
Date: Tue, 7 Sep 2010 17:23:36 -0700
Message-ID: <AANLkTimSiD5U9epkbtYkV4rfJJxVq2cEr97Apyx1ixt=@mail.gmail.com>
To: nathan@webr3.org
Cc: Jian Li <jianli@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>, Vladimir Vukicevic <vladimir@mozilla.com>
On Tue, Sep 7, 2010 at 4:19 PM, Nathan <nathan@webr3.org> wrote:
> Jian Li wrote:
>> Hi,
>> Several specs, like File API and WebGL, use ArrayBuffer, while other spec,
>> like XMLHttpRequest Level 2, use ByteArray. Should we change to use the
>> same
>> name all across our specs? Since we define ArrayBuffer in the Typed Arrays
>> spec (
>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html),
>> should we favor ArrayBuffer?
>> In addition, can we consider adding ArrayBuffer support to BlobBuilder,
>> FormData, and XMLHttpRequest.send()?
> which reminds me, I meant to ask if the aforementioned TypedArray spec
> should be brought in to webapps / w3c land? seems to complement the other
> base types used in webidl etc rather well + my gut reaction was why isn't
> this standardized within w3c?

There's no particular reason why the Typed Array spec is being
standardized in the Khronos group, aside from the fact that these
array-like types originated in the WebGL spec and have evolved to meet
use cases specified by WebGL. We have been hoping that they would have
uses outside of WebGL, and some discussions have occurred with working
groups such as TC39 to see how they might be better specified and
standardized. We'd be open to hosting the spec development elsewhere.

Vlad mentioned to me off-list that Mozilla has implemented an
experimental mozResponseArrayBuffer on XHR objects, and will likely do
the same on the File API to add a readAsArrayBuffer alongside
readAsBinaryString etc.

Received on Wednesday, 8 September 2010 00:24:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC