On 2012-03-28 12:01, Mark Callow wrote:
On 28/03/2012 18:45, Boris Zbarsky wrote:
On 3/28/12 2:40 AM, Mark Callow wrote:
Because you said "JS-visible state (will) always be little-endian".
So? I don't see the problem, but maybe I'm missing something...
The proposal is that if you take an array buffer, treat it as a
Uint32Array, and write an integer of the form W | (X<< 8) | (Y<< 16)
| (Z<< 24) into it (where W, X, Y, Z are numbers in the range
[0,255]), then the byte pattern in the buffer ends up being WXYZ, no
matter what native endianness is.
Reading the first integer from the Uint32Array view of this data would
then return exactly the integer you started with...
So now you are saying that only the JS-visible state of ArrayBuffer is
little-endian. The JS-visible state of int32Array, etc. is in
platform-endiannesss. I took your original statement to mean that all
JS-visible state from TypedArrays is little-endian.
Regards
-Mark
Getting rather messy this isn't it?
arrayBuffer should be native endianess (native as to the JS engine),
anything else does not logically make sense for me as a programmer.
xhr.responseType = 'arraybuffer' on the other hand is a bigger issue as
a client program (browser) could be little endian but the server could
be big endian.
So in this case it would make sense if xhr.responseType = 'arraybuffer'
and xhr.responseType = 'arraybuffer/le' was the same and
xhr.responseType = 'arraybuffer/be' was for big endian/network byte order.
Personally I think that arrayBuffer should be native, and that
xhr.responseType should be ambiguous, in other words let the
implementers make sure of the endianess.
A client can easily ask for a desired endianess from the server by using
normal arguments during the query, or possibly a xhr.responseEndian=''
property if that makes sense at all.
--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
