Encoding

[thehowl]

As more powerful encodings may come in the future, I thought about a new key in the json object, e, which specifies the encoding of the object, using a two character string:

• The first character representing the actual encoding of bytes. i.e. a for base64, b for base65536, - if just sending raw bytes with no encoding in the middle
• The second one representing compression, allowing for gzip compression right in the client.

Whaddya think?

[pixeldesu]

why not using a v or r key that specifies the revision used and the clients adapting to that?

like for now, this would be the following:

• "r": 1 would be the initial base64 encoding
• "r": 2 would be the hacky binary -> base64 -> base65536 fallback for the Ruby client
• "r": 3 would be base65536 encoding

[thehowl]

I thought about that previously, too. The main issue is that I think it should be possible to allow a client to choose between gzip-encoding or not. Basically, this issue implies the possibility for a client/library to automagically gzip and have the client on the other side automatically decompress without having the end user to do any compression/decompression (much like gzip on HTTP)

Anyway, either r or the one I proposed in OP, we need to have a versioning system in the JSON itself.