- From: Joshua Bell <jsbell@chromium.org>
- Date: Wed, 14 Mar 2012 10:08:14 -0700
On Wed, Mar 14, 2012 at 9:14 AM, Joshua Bell <jsbell at chromium.org> wrote: > On Wed, Mar 14, 2012 at 1:14 AM, Cedric Vivier <cedricv at neonux.com> wrote: > >> >> For this, base64 encoding/decoding is typically used (so that it >> doesn't conflict with the XML or JSON container) and thus more or less >> efficiently implemented in JavaScript (just like we had to >> encode/decode strings in JS to/from XHR a while ago). >> >> Would it make sense to support encoding="base64" in this API? > > > Having implemented a library that handled both text encodings and > base16/base64 encoding, I can offer the opinion that the nomenclature gets > very confusing since the encode/decode semantics are reversed. > > binary_buffer = encode(text_content) > text_content = decode(binary_buffer) > > vs. > > binary_buffer = decode(base64_data) > base64_data = encode(binary_buffer) > > When you try to unify these and have the same API accept "UTF-8" and > "BASE64" encodings by name it's difficult to keep track of which of > encode/decode you want; one will seem backwards. (This is one advantage of > the atob()/btoa() API naming approach.) > And extending that thought, such confusion is lessened if you can avoid the loaded words encode/decode and associate the operations with either one of the target types, e.g. buffer.writeString/readString, or string.toBuffer/fromBuffer
Received on Wednesday, 14 March 2012 10:08:14 UTC