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. 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. If we could choose anything but JSON, we would, but the customer spec requires an even nastier and slower text format than JSON. We expect to win the argument to get them to "upgrade" to JSON, but anything better than that is years away. Change is hard for big governmental orgs. 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. Niall