On Wed, Mar 14, 2012 at 9:14 AM, Joshua Bell <[email protected]> wrote:
> On Wed, Mar 14, 2012 at 1:14 AM, Cedric Vivier <[email protected]> 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
