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

[Jonas Sicking]

On Mon, Aug 12, 2013 at 10:27 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell <jsbell at google.com> wrote:
>> 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?
>
> Yes, since Firefox 18 (since Firefox 20 in workers).

I assume we are talking about TextEncoder/TextDecoder here, and not
new versions of atob and btoa.

If so, yes, we've been shipping that for a while now.

>> 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).
>
> I can't really speak for Gecko, but I suspect we wouldn't like
> changing it over half a year after deploying it. Jonas?

I guess we'd have to do a cost/benefit analysis. What is it that
people want to change about the current API, and why?

Moving to new function names might be doable, by implementing the new
names and adding warnings to the old ones. But we should consider the
confusion it will cause, and how much it will delay deployment.

>> 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?
>
> Adding that seems fine.

I don't have strong opinions either way.

I don't think that base64 encoding fits with the current
TextEncoder/Decoder API. Not because of names, but because base64
encoding is by nature opposite. I.e. the encoded format is in string
form, whereas the decoded format is in binary form.

I.e. encodings like utf8 and friends encode string data into binary
data. base64 encodes binary data into string data.

/ Jonas