W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

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

From: Anne van Kesteren <annevk@annevk.nl>
Date: Mon, 12 Aug 2013 18:27:04 +0100
Message-ID: <CADnb78jEQsSDX+B0kfF687bO4DrLuJciKi5RRm+698vpbHOOCg@mail.gmail.com>
To: Joshua Bell <jsbell@google.com>, Jonas Sicking <jonas@sicking.cc>
Cc: WHATWG <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, kg@luminance.org, Chang Shu <cshu01@gmail.com>
On Mon, Aug 12, 2013 at 6:16 PM, Joshua Bell <jsbell@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).

> 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?

> 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.

Received on Monday, 12 August 2013 17:27:29 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC