[whatwg] API for encoding/decoding ArrayBuffers into text

[Charles Pritchard]

On 3/16/2012 3:26 PM, Glenn Maynard wrote:
> On Fri, Mar 16, 2012 at 4:44 PM, Charles Pritchard <chuck at jumis.com 
> <mailto:chuck at jumis.com>> wrote:
>
>     The DataView set of methods already does this work. The raw arrays
>     are supposed to have platform endianness.
>
>
> That's wrong.  This is web API design 101; everyone should know better 
> than this by now.  Exposing platform endianness is setting the 
> platform up for massive incompatibilities down the road.

I make mistakes all the time with UTF8 and raw string arrays. I make 
mistakes all the time with endianness.

Low level API design 101; everyone working with low level APIs makes 
mistakes.

> In reality, the spec is moot here: if anyone does implement typed 
> arrays on a production big-endian system, they're going to make these 
> views little-endian, because doing otherwise would break countless 
> applications, essentially all of which are tested only on 
> little-endian systems.  Web compatibility is a top priority to browser 
> implementations.

It's up to programmers to code defensively. More-so with multi-platform 
multi-vendor deployments than walled gardens.
Authors should be using the spec as written, it only takes one target 
system to use big-endian.

It doesn't harm anything for a vendor to implement as little-endian, as 
most authors assume and test on little endian.
It may cause some harm to alter the spec so as to remove the requirement 
that coders account for both.

>
> (DataView isn't relevant here; it's used for different access 
> patterns.  To access arrays of data embedded in an ArrayBuffer, you 
> use views, not DataView.  Use DataView if you have a packed data 
> structure with variable-size fields, such as the metadata in a ZIP 
> local file header.)
I use the subarray pattern frequently. DataView is not much different 
than using subarray.

Use DataView when it's easier than ArrayBufferView and available.