[whatwg] API for encoding/decoding ArrayBuffers into text
chuck at jumis.com
Fri Mar 16 15:48:27 PDT 2012
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
> 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
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.
More information about the whatwg