Re: [review][JSON] Review of JSON starts today: Sept 14 - Sept 23

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2020-09-16 13:33:14

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