Vinnie Falco wrote:
I think the best way to support this is as follows:
1. Fork the Boost.JSON repository, rename it to Boost.CBOR 2. Add support for binary strings to the cbor::value type 3. Add support for extensions to the cbor::value type
This misses the point quite thoroughly; it doesn't "support this" at all. The point of "binary JSON" is that people already have a code base that uses JSON for communication and - let's suppose - boost::json::value internally. Now those people want to offer an optional, alternate wire format that is not as wasteful as JSON, so that the other endpoint may choose to use it. But they most definitely don't want to rewrite or duplicate all their code to be cbor::value based, instead of, or in addition to, json::value based. It doesn't matter that CBOR supports extensions, because they don't. And it may not even matter that the hypothetical CBOR-to-json::value parser doesn't support binary values, because their protocol, being originally JSON-based, doesn't. (There is actually a fully compatible way to support "binary values" in json::value, but it will require some hammering out.)