From 74a64da2cd30ce45a4adb0533cafdbe285aba1a76cb75c459cd8b4b6865849b8 Mon Sep 17 00:00:00 2001
From: Sergey Matveev <stargrave@stargrave.org>
Date: Sun, 6 Oct 2024 21:33:54 +0300
Subject: [PATCH] More comparison

---
 spec/index.texi | 87 ++++++++++++++++++++++++++++++++-----------------
 1 file changed, 58 insertions(+), 29 deletions(-)

diff --git a/spec/index.texi b/spec/index.texi
index 9d67c07..7bbbc3e 100644
--- a/spec/index.texi
+++ b/spec/index.texi
@@ -29,37 +29,66 @@ of structured data. But why!?
 
 Are not there any satisfiable codecs?
 
-@table @asis
-@item @url{https://wiki.theory.org/BitTorrentSpecification#Bencoding, Bencode}
-    Is very simple and deterministic. But it has a few data types, even
-    lacking human-readable strings.
-@item @url{https://www.ietf.org/archive/id/draft-rivest-sexp-08.html, Canonical S-Expressions}
-    Is another interesting candidate with relatively simple encoding,
-    but without enough data types.
-@item @url{https://bsonspec.org/, BSON}
-    Is pretty simple too, having enough data types. But it is not able
-    to transfer strings and lists longer than their 32-bit length. Also
-    that encoding is not compact.
-@item @url{https://msgpack.org/, MessagePack}
-    Is another good candidate with rather simple encoding. But it still
-    can not transfer large (>4GiB) strings. And it does not have
-    deterministic encoding rules.
-@item @url{https://datatracker.ietf.org/doc/html/rfc8949, CBOR}
-    Looked like the promising one, having nearly the same aims as we
-    did, even with Deterministic Encoded CBOR version description and
-    being pretty compact in binary form.
-
-    But it is the @strong{most} complicated from all the codecs
-    mentioned above, failing their main claim of being simple. Streaming
-    encoding can reduce both the code size and memory usage of your
-    application, but deterministic CBOR encoding prohibits it.
-
-    Moreover hardly you will find CBOR libraries supporting strict
-    validation of deterministically encoded CBOR structures.
-@end table
+@multitable @columnfractions .30 .10 .10 .10 .10 .10 .10 .10
+
+@headitem name @tab
+    Schemaless @tab
+    Simple @tab
+    Deterministic @tab
+    Streamable @tab
+    Compact @tab
+    Large strings @tab
+    Many types
+
+@item ASN.1 DER @tab N @tab @strong{N} @tab Y @tab N @tab ~ @tab Y @tab ~
+@item ASN.1 CER @tab N @tab @strong{N} @tab Y @tab Y @tab ~ @tab Y @tab ~
+@item @url{https://protobuf.dev/, Protocol Buffers}
+    @tab N @tab ~ @tab N @tab N @tab Y @tab N @tab Y
+@item @url{https://flatbuffers.dev/, FlatBuffers}
+    @tab Y @tab N @tab N @tab N @tab N @tab Y @tab Y
+@item @url{https://bsonspec.org/, BSON} @tab
+    Y @tab Y @tab N @tab N @tab N @tab N @tab Y
+@item @url{https://msgpack.org/, MessagePack} @tab
+    Y @tab Y @tab N @tab N @tab N @tab N @tab Y
+@item @url{https://datatracker.ietf.org/doc/html/rfc8949, CBOR} @tab
+    Y @tab N @tab N @tab Y @tab Y @tab Y @tab Y
+@item Deterministic Encoded CBOR @tab
+    Y @tab N @tab Y @tab N @tab Y @tab Y @tab Y
+@item @url{http://cr.yp.to/proto/netstrings.txt, Netstring} @tab
+    Y @tab Y @tab Y @tab N @tab N @tab Y @tab N
+@item @url{https://wiki.theory.org/BitTorrentSpecification#Bencoding, Bencode} @tab
+    Y @tab Y @tab Y @tab Y @tab N @tab Y @tab N
+@item @url{https://en.wikipedia.org/wiki/Canonical_S-expressions, Canonical S-expression}
+    @tab Y @tab Y @tab Y @tab Y @tab N @tab Y @tab N
+@item YAC @tab
+    Y @tab Y @tab Y @tab Y @tab Y @tab Y @tab Y
+
+@end multitable
+
+@itemize
+@item Schemaless formats are easier to deal with in heterogeneous
+    environments, with wide range of software. But with the price of
+    bigger size and harder validation as a rule.
+@item Streamable formats allow you to send a part of the data
+    immediately, for example element of the list or map. Simplifying
+    encoder and requiring less memory usage. All formats who needs to
+    know the size of maps/lists are not streamable.
+@item Compactness means small amount of bytes overhead for the given
+    data. For example any codec with ASCII decimal lengths of the
+    strings or integers representation is not compact.
+@item "Large strings" is a strings bigger than 4GiB. Some codecs allow
+    you to send only even 2GiB of data in a single chunk. That will
+    force you code and structures be more complex when dealing with big
+    data transfer
+@item "Many types" is a subjective thing of course. If codec can encode
+    everything JSON can, then it is enough types. ASN.1 codecs support
+    many various types, but they can not represent arbitrary map.
+@item Hardly you will find CBOR libraries supporting strict validation
+    of deterministically encoded CBOR structures.
+@end itemize
 
 YAC deals with those problems by using only streaming deterministic
-encoding. YAC Ain't a CBOR. Its other important differences:
+encoding. Its other important differences:
 
 @itemize
 @item It lacks any kind of tagging support, making the whole codec
-- 
2.50.0