[whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob

[Joshua Bell]

Back from a vacation, sorry about the late reply - hopefully still useful.

On Wed, Aug 7, 2013 at 3:02 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu <cshu01 at gmail.com> wrote:
>
> > If we plan to enhance the Encoding spec, I personally prefer a new pair
> of
>
> BinaryDecoder/BinaryEncoder, which will be less confusing than reusing
> > TextDecoder/TextEncoder.
> >
>
> I disagree with the idea of adding a new method for something that behaves
> exactly like something we already have, just to give it a different name.
>
> (It may not be too late to rename those functions, if nobody has
> implemented them yet, but I'm not convinced it's much of a problem.)
>

FWIW, I've landed an experimental (behind a flag) implementation of the API
in Blink/Chromium; changing it is definitely possible for us. I believe Moz
is shipping it web-exposed already in FF?

To recap history: early iterations of the Encoding API proposal did have
base64 but it was removed with the suggestion to extend atob()/btoa()
instead, and due to the confusion around the encode/decode verbs. If the
APIs were something like StringToBytesConverter::convert() and
BytesToStringConverter::convert() it would make more sense for encoding of
both text (use StringToBytes) and binary data (use BytesToString).

While we're re-opening this can of worms, there's been a request to add a
flush() method to the TextEncoder/TextDecoder objects, which would behave
the same as calling encode(null, {stream: false}) / decode(null,
{stream:false}) but make the code more readable. This fails the "adding a
new method for something that behaves exactly like something we already
have" test. Opinions?