Back from a vacation, sorry about the late reply - hopefully still useful. On Wed, Aug 7, 2013 at 3:02 PM, Glenn Maynard <[email protected]> wrote:
> On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu <[email protected]> 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?
