The conflict here seems to be between people who think any arbitrary valid msgpack stream should be decodable into a specific object graph, and those who assume msgpack will be used to implement a protocol where only messages of a predefined format should be allowed - hence the decoding app will know beforehand what should be a string and what shouldn't.
The conflict is unresolvable until the participants agree on which of these two distinct things msgpack should be.
I don't see the conflict here. Spend one bit per string encoding whether it's UTF-8 data or a binary blob.
* The people who use it to implement protocols already have to deal with types, e.g., expected a number but got a string. So one more type is not a big deal.
* The people who use it to create discoverable profiles will... use JSON no matter how good MessagePack gets.
That's not the direction I was headed when I started writing, but I don't think the first group you mentioned even exists.
Comments
The conflict here seems to be between people who think any arbitrary valid msgpack stream should be decodable into a specific object graph, and those who assume msgpack will be used to implement a protocol where only messages of a predefined format should be allowed - hence the decoding app will know beforehand what should be a string and what shouldn't.
The conflict is unresolvable until the participants agree on which of these two distinct things msgpack should be.
I don't see the conflict here. Spend one bit per string encoding whether it's UTF-8 data or a binary blob.
* The people who use it to implement protocols already have to deal with types, e.g., expected a number but got a string. So one more type is not a big deal.
* The people who use it to create discoverable profiles will... use JSON no matter how good MessagePack gets.
That's not the direction I was headed when I started writing, but I don't think the first group you mentioned even exists.