On 16.09.20 15:33, Niall Douglas via Boost wrote:
On 16/09/2020 08:31, Rainer Deyke via Boost wrote:
On 15.09.20 16:45, Peter Dimov via Boost wrote:
Rainer Deyke wrote:
I vote to CONDITIONALLY ACCEPT Boost.JSON, conditional on the inclusion of code for parsing and serializing boost::json::value as CBOR.
I find this condition is too strict. You basically say that you'd rather not see the proposed Boost.JSON enter Boost until CBOR is implemented, which may happen six months from now. So people who don't have a need for CBOR will have to wait until Boost 1.77, which doesn't really help anyone.
Actually I would like to see Boost.JSON in Boost, with or without CBOR. However, I can't in good conscience vote to accept a library that I am unwilling to use. Boost should not be a graveyard of well-designed but unused libraries.
As I explained in my review, if my condition is not met, I would like my vote to be counted as ABSTAIN, not REJECT. I am hoping that Boost.JSON will get enough votes to accept to make it into Boost, with or without CBOR support.
If the proposed library were called Boost.Serialisation2 or something, I would see your point.
But it's called Boost.JSON. It implements JSON. It does not implement CBOR. I don't think it's reasonable to recommend a rejection for a library not doing something completely different to what it does.
I see CBOR not as a separate format, but as an encoding for JSON (with some additional features that can safely be ignored). I use it to store and transmit JSON data, and would not use it for anything else. JSON data exists independently of the JSON serialization format. This is in fact a core principle of Boost.JSON: the data representation exists independently of the serialization functions.
Speaking wider that this, if the format here were not specifically JSON, I'd also be more sympathetic - binary as well as text serialisation/deserialisation is important. But JSON is unique, most users would not choose JSON except that they are forced to do so by needing to talk to other stuff which mandates JSON.
At work we have this lovely very high performance custom DB based on LLFIO. It has rocking stats. But it's exposed to clients via a REST API, and that means everything goes via JSON. So the DB spends most of its time fairly idle compared to what it is capable of, because JSON is so very very slow in comparison.
This is exactly the sort of problem that CBOR excels at. The server produces JSON. The client consumes JSON. Flip a switch, and the server produces CBOR instead. Ideally the client doesn't have to be changed at all. One line of code changed in the server, and suddenly you have twice the data throughput.
In any case, CBOR is actually a fairly lousy binary protocol. Very inefficient compared to alternatives. But the alternatives all would require you to design your software differently to what JSON's very reference count centric design demands.
It may be lousy as a general-purpose binary protocol, but it's a fairly good binary JSON representation. Which is why it belongs in a JSON library if it belongs anywhere. -- Rainer Deyke (rainerd@eldwood.com)