[whatwg] API for encoding/decoding ArrayBuffers into text

[Glenn Maynard]

On Tue, Mar 27, 2012 at 7:12 PM, Kenneth Russell <kbr at google.com> wrote:

>   - I think it should reference DataView directly rather than
> ArrayBufferView. The typed array spec was specifically designed with
> two use cases in mind: in-memory assembly of data to be sent to the
> graphics card or audio device, where the byte order must be that of
> the host architecture;


This is wrong, broken, won't be implemented this way by any production
browser, isn't how it's used in practice, and needs to be fixed in the
spec.  It violates the most basic web API requirement: interoperability.
Please see earlier in the thread; the views affected by endianness need to
be specced as little endian.  That's what everyone is going to implement,
and what everyone's pages are going to depend on, so it's what the spec
needs to say.  Separate types should be added for big-endian (eg.
Int16BEArray).

I also disagree that it should use DataView.  Views are used to access
arrays (including strings) within larger data structures.  DataView is used
to access packed data structures, where constructing a view for each
variable in the struct is unwieldy.  It might be useful to have a helper in
DataView, but the core API should work on views.

 - It would be preferable if the encoding API had a way to avoid
> memory allocation, for example to encode into a passed-in DataView.
>

This was an earlier design, and discussion led to it being removed as a
premature optimization, to simplify the API.  I'd recommend reading the
rest of the thread.

-- 
Glenn Maynard