- From: Joshua Bell <jsbell@google.com>
- Date: Mon, 12 Aug 2013 10:16:59 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: WHATWG <whatwg@lists.whatwg.org>, kg@luminance.org, Chang Shu <cshu01@gmail.com>
Back from a vacation, sorry about the late reply - hopefully still useful.
On Wed, Aug 7, 2013 at 3:02 PM, Glenn Maynard <glenn@zewt.org> wrote:
> On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu <cshu01@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?
Received on Monday, 12 August 2013 17:17:24 UTC