msgpack.org probably shouldn't be promoting it as a "perfect replacement", when valid messages which have no JSON equivalent have already been seen in practice. At best it's a superset, and if none of the implementations can confine you to a JSON-compatible subset (no byte strings, no int64, no non-string keys) which assures interop, that's a problem.
Mostly I wish people would agree on a schema and use ASN.1 PER, rather than choosing from the ever-growing list of binary type-length-value formats which put a redundant copy of the schema on the wire in every message (making them neither small nor readable). I've never had occasion to do anything useful with a message whose format wasn't already known when I wrote the code.
Comments
msgpack.org probably shouldn't be promoting it as a "perfect replacement", when valid messages which have no JSON equivalent have already been seen in practice. At best it's a superset, and if none of the implementations can confine you to a JSON-compatible subset (no byte strings, no int64, no non-string keys) which assures interop, that's a problem.
Mostly I wish people would agree on a schema and use ASN.1 PER, rather than choosing from the ever-growing list of binary type-length-value formats which put a redundant copy of the schema on the wire in every message (making them neither small nor readable). I've never had occasion to do anything useful with a message whose format wasn't already known when I wrote the code.