W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: BlobBuilder.append() should take ArrayBufferView in addition to ArrayBuffer

From: Jonas Sicking <jonas@sicking.cc>
Date: Sun, 29 Apr 2012 12:41:17 -0700
Message-ID: <CA+c2ei9ZNNZFz_tF81+R1Y59oirgYgek+V-_hXRC4Xju=Tc9vw@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Arun Ranganathan <aranganathan@mozilla.com>, Anne van Kesteren <annevk@opera.com>, David Herman <dherman@mozilla.com>, Eric U <ericu@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On Sat, Apr 28, 2012 at 7:54 AM, Glenn Maynard <glenn@zewt.org> wrote:
> On Sat, Apr 28, 2012 at 3:45 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> We should not have readAsArryBufferView since there's a ton of
>> different types of ArrayBufferViews. Instead we should just return an
>> ArrayBuffer and let people construct ArrayBufferViews or DataViews
>> into that as they see fit.
>
>
> It would have made sense to return an Int8Array in all cases instead of an
> ArrayBuffer: it's probably by far the most common actual data type, treating
> buffers as char* by default isn't unusual, and it allows passing the results
> of one API directly into another API.  Having API inputs and outputs use two
> different types is pretty asymmetric.
>
> (I say that in past tense; it's probably too late to fix this.  Also, I'd
> rather live with that asymmetry than have every single ArrayBuffer entry
> point have separate ArrayBuffer and ArrayBufferView overloads.)

I don't know what you are using as basis for the "it's probably by far
the most common actual data type" statement.

The whole point of the ArrayBuffer/ArrayBufferView split is that
ArrayBuffers represent data of which you don't know the type, whereas
ArrayBufferView is for when you know the type.

You might not like that design (I don't), but it's what we have.
Hopefully ES6 will grow something better at which time we can support
that.

/ Jonas
Received on Sunday, 29 April 2012 19:42:16 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT