You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

IDIEP-75
Author
Sponsor
Created

  

Status
DRAFT


Motivation

Thin clients need a standardized way to serialize data for Table and Key-Value APIs. In 2.x, we used the same Ignite binary format that was used for server communication and data storage. However, in 3.x there are different formats for data storage and transmission (TODO: links), and those formats are not meant to be used by thin clients.

Description

Requirements

The goal is to find an existing serialization format that satisfies the following requirements:

  • Binary (as opposed to text, like JSON, for performance reasons)
  • Supports nested object graphs
  • Supports primitives, not only objects (for example, integer or Guid value can be serialized independently)
  • Schemaless: any object of any type can be written without prior set up
  • Can work without classes ("binary mode" in terms of 2.x): servers should be able to inspect the structure in serialized form
  • Extensible (can add custom types)
  • Well-supported implementations in all languages of interest (Java, C#, C++, Python, JavaScript, PHP)
    • With compatible license
  • Fast and compact

Comparison

NameCommentsLicense
MessagePack
Java: Apache 2.0, C#: MIT, C++: MIT(nlohmann/json), TODO
CBORBased on MessagePack. CBOR is standardized (RFC7049), but MessagePack is simpler. "Use MsgPack instead of CBOR": https://diziet.dreamwidth.org/6568.html
FlexBuffers"Schemaless cousin of Google's FlatBuffers"

Avro



Thrift

BSON

Non-suitable popular formats:

NameReason
ProtoBufSchema required






Risks and Assumptions

// TODO: ?

Discussion Links

// TODO

Reference Links

Tickets

key summary type created updated due assignee reporter priority status resolution

JQL and issue key arguments for this macro require at least one Jira application link to be configured

  • No labels