[whatwg] API for encoding/decoding ArrayBuffers into text

[Joshua Bell]

On Wed, Mar 21, 2012 at 12:42 PM, Anne van Kesteren <annevk at opera.com>wrote:

> On Wed, 21 Mar 2012 01:27:47 -0700, Jonas Sicking <jonas at sicking.cc>
> wrote:
>
>> This leaves us with 2 or 3. So the question is if we should support
>> streaming or not. I suspect doing so would be worth it.
>>
>
> For XMLHttpRequest it might be, yes.
>
> I think we should expose the same encoding set throughout the platform.
> One reason to limit the encoding set initially might be because we have not
> all converged yet on our encoding sets. Gecko, Safari, and Internet
> Explorer expose a lot more encodings than Opera and Chrome.
>

Just to throw it out there - does anyone feel we can/should offer
asymmetric encode/decode support, i.e. supporting more encodings for decode
operations than for encode operations?

As for the API, how about:
>
>  enc = new Encoder("euc-kr")
>  string1 = enc.encode(bytes1)
>  string2 = enc.encode(bytes2)
>  string3 = enc.eof() // might return empty string if all is fine
>
> And similarly you would have
>
>  dec = new Decoder("shift_jis")
>  bytes = dec.decode(string)
>
> Or alternatively you could have a single object that exposes both encode()
> and decode() and tracks state for both:
>
>  enc = new Encoding("gb18030")
>  bytes1  = enc.decode(string1)
>  string2 = enc.encode(bytes2)


That's the direction my thinking was headed. Glenn pointed out that the
state that's implicitly captured in the above objects could instead be
returned as an explicit but opaque state object that's passed in and out of
stateless functions. As a potential user of the API, I find the above
"object-oriented" style easier to understand.

Re: Encoding object vs. an Encoder/Decoder pair - I'd prefer the latter as
it makes the state being captured and any methods/attributes to interrogate
the state clearer.

Bikeshedding on the name - we'd have to put "String" or "Text" in there
somewhere, since audio/video/image codecs will likely want to use similar
terms.