Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

* Boris Zbarsky wrote:
>On 11/10/10 4:39 PM, Bjoern Hoehrmann wrote:
>> In most cases you do not need to store the bytes in order to get them
>> back, you can just apply the character encoding scheme used to decode
>> the bytes to the string and you'll have the original byte string, so
>> long as the character encoding scheme is bijective, which is true for
>> most of the relevant schemes like UTF-8 and UTF-16.
>Neither of those is bijective.
>In particular, both encoding schemes are not surjective as functions 
>from Unicode strings onto byte streams (that is, there are such things 
>as invalid byte sequences for both of them).  Therefore they can't 
>possibly be bijective.  Specifically, invalid byte sequences typically 
>lead to U+FFFD ending up in the Unicode string no matter what the 
>particular values of the invalid bytes were.
>> like with UTF-8 encoded strings that are not-wellformed
>Right.  See above.  Note that most cases when the data is really desired 
>as a byte array will in fact not be valid UTF-8.

The objection that I would expect is that your decoder does not inform
higher level code whether there was an error in the stream, you do not
like to change its API, and scanning for the replacement character un-
conditionally is objectionable too; or that it's hard to come up with
good and simple rules for when to dispose of a redundant objects. That
you can't do this optimization in every last edge case, well, that does
not necessarily justify adding new XHR-like interfaces, or complicating
things for authors with new parameters and surprising behavior.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · 

Received on Thursday, 11 November 2010 02:53:54 UTC