[whatwg] API for encoding/decoding ArrayBuffers into text

[Glenn Maynard]

On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren <annevk at opera.com> wrote:

> Another way would be to have a second optional argument that indicates
> whether more bytes are coming (defaults to false), but I'm not sure of the
> chances that would be used correctly. The reasons you outline are probably
> why many browser implementations deal with EOF poorly too.


It might not improve it, but I don't think it'd be worse.  If you didn't
use it correctly for an encoding where it matters, the breakage would be
obvious.

Also, the previous "automatically-streaming" API has another possible
misuse: constructing a single encoder, then calling it repeatedly for
unrelated strings, without calling eof() between them (trailing bytes would
become U+FFFD in the next string).  That'd be a less likely mistake with
this, too.

Here's a suggestion, working from that:

encoder = Encoder("euc-kr");
view = encoder.encode(str1, {continues: true});
view = encoder.encode(str2, {continues: true});
view = encoder.encode(str3, {continues: false});

An alternative way to end the stream:

encoder = Encoder("euc-kr");
view = encoder.encode(str1, {continues: true});
view = encoder.encode(str2, {continues: true});
view = encoder.encode(str3, {continues: true});
view = encoder.encode("", {continues: false});
// or view = encoder.encode(""); // equivalent; continues defaults to false
// or view = encoder.encode(); // maybe equivalent, if the first parameter
is optional

The simplest usage is concise enough that we don't really need a separate
str.encode() method:

view = Encoder("euc-kr").encode(str);

If it has an eof() method, it'd just be a literal wrapper for
encoder.encode(), but it can probably be omitted.

-- 
Glenn Maynard