[whatwg] API for encoding/decoding ArrayBuffers into text

[Jonas Sicking]

On Mon, Mar 19, 2012 at 6:14 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Mon, Mar 19, 2012 at 7:33 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>>
>> What value are we adding, and to whom, by keeping the list the
>> smallest it can be, even when that means keeping the lists of
>> supported encodings different between different APIs?
>
> Not needlessly extending support for legacy encodings means there's no
> chance of this API inadvertently causing proliferation of those encodings.
> That benefits everyone who might come in contact with that data, and
> increases the odds of being able to remove some of those encodings from the
> platform entirely.

It seems unlikely to me that adding support for an encoding here will
make it harder to eradicate the encoding from the web.

>> The concrete costs are that authors will have to learn which encodings
>> work where, and that implementations need to keep separate lists of
>> supported encodings in different APIs.
>
>
> Authors don't need to learn that; all they care about is if the encoding
> they're trying to use works.  Nobody memorizes lists of encodings.

Why are encodings different than other parts of the API where you
indeed have to know what works and what doesn't.

> It also means that browsers need to be able to encode to each of these
> encodings, and encoding for all of them needs to be specified, which I think
> is currently unneeded.  (Unless we go the asymmetric encoding/decoding
> route, supporting only decoders for legacy charsets.  If this is the only
> reason that'd all have to be specified, that's probably another reason to
> consider it...)
>
> Supporting streaming decoding for modal encodings, such as ISO-2022-CN,
> might also be a burden: it means implementations would be required to
> support stateful, incremental decoding for that charset, which is more
> complicated than most encodings (which are stateless).  Many implementations
> probably do support that, but I don't think it's currently mandatory, and it
> would complicate any streaming API.  Stateful encodings need to die even
> more than other legacy encodings; I hope this API doesn't have to support
> any of them.

UTF8 is stateful, so I disagree.

/ Jonas