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