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

From: Rainer Deyke (rdeyke_at_[hidden])
Date: 2020-09-16 14:44:30

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_at_[hidden])