KEKS

    KEKS is compact, deterministic, concise and streaming binary
    serialisation format. It is aimed to be lightweight in terms of CPU,
    memory, storage and codec implementation size usage. It supports wide
    range of data types, making it able to transparently replace JSON.

    KEKS means: kompakt, entschlossen, knapp, strömen.

    But why!? Because there is no satisfiable codec for all set of
    requirements below.

    * It *must* be schema-less format. Schema-aware ones have their definite
      valuable advantages, but also a complication drawbacks and
      non-friendliness to humans.
    * Its encoder/decoder *must* be very compact and small in terms of code
      and branches amount, to reduce attack surface on the codec itself.
    * It *must* support enough data types for being able at least to replace
      JSON transparently.
    * Its encoding *must* be deterministic -- there must be only a single
      representation of the structured data, allowing its usage in
      cryptography-related contexts.
    * Its encoder *should* be streaming-friendly, making encoder
      simpler and allowing memory-constrained systems workability.
    * Its encoding *should* be reasonably compact, to be friendly to
      storage space constrained systems.
    * It *should* be frugal to CPU usage for both performance/memory
      constrained and high data volume applications.
    * It *should* differentiate binary and human-readable strings.
    * It *would* be nice to have human-editable intermediate representation.

    Are not there any satisfiable [codecs]?

                | simple | deterministic | streamable | compact
    ------------+--------+---------------+------------+--------
    ASN.1 DER   | N      | Y             | N          | N
    ASN.1 CER   | N      | Y             | Y          | N
    JSON        | N      | N             | Y          | N
    BSON        | Y      | N             | N          | N
    MessagePack | Y      | N             | N          | Y
    CBOR        | N      | N             | Y          | Y
    dCBOR       | N      | Y             | N          | Y
    Netstrings  | Y      | Y             | N          | ~
    Bencode     | Y      | Y             | Y          | ~
    CSExp       | Y      | Y             | Y          | ~
    KEKS        | Y      | Y             | Y          | Y

                | big | bin | UTF |     | big |      |     |
                | str | str | str | int | int | list | map | time
    ------------+-----+-----+-----+-----+-----+------+-----+-----
    ASN.1 DER   | Y   | Y   | Y   | Y   | Y   | Y    | Y   | Y
    ASN.1 CER   | Y   | Y   | Y   | Y   | Y   | Y    | Y   | Y
    JSON        | Y   | N   | Y   | Y   | Y   | Y    | Y   | N
    BSON        | N   | Y   | Y   | Y   | N   | Y    | Y   | Y
    MessagePack | N   | Y   | Y   | Y   | N   | Y    | Y   | N
    CBOR        | Y   | Y   | Y   | Y   | N   | Y    | Y   | N
    dCBOR       | Y   | Y   | Y   | Y   | N   | Y    | Y   | N
    Netstrings  | Y   | Y   | N   | N   | N   | N    | N   | N
    Bencode     | Y   | Y   | N   | Y   | Y   | Y    | Y   | N
    CSExp       | Y   | Y   | N   | N   | N   | Y    | N   | N
    KEKS        | Y   | Y   | Y   | Y   | Y   | Y    | Y   | Y

    Note about CBOR:

    * Hardly you will find wide range of CBOR libraries supporting strict
      validation of deterministically encoded CBOR structures.
    * Tagged string/integer can not be taken as a viable first-class
      bigint/datetime data support, because many decoders do not support
      tags and won't be able to interpret/validate them.
    * Non-string map keys very complicates representation process for
      dynamically types languages.

      [INSTALL]
    [encoding/]
      [schema/] -- Structure validation against schemas
          [cm/] -- Cryptographic Messages
          [RPC] -- Remote Procedure Call
       [THANKS]

    Announcements go to:
    => maillist

    Copyright © 2024-2025 Sergey Matveev <stargrave@stargrave.org>