[Feature Request] Add Postcard Encoding

[mattico]

🚀 Feature Request

Implement code generation for the postcard encoding.

Motivation

Postcard is a popular encoding within the niche of Rust embedded code. It is a simple binary encoding optimized for embedded devices.

Pitch

I'm going to be working on implementing postcard encoding with serde-reflection, and would like to upstream this code if possible.

My project only needs the C# runtime, should we require a runtime implementation for each language? In the longer term this MxN requirement could become onerous.

The maintenance burden should be considered for such a niche encoding. Postcard is very simple and fairly stable at this point, but it is not 1.0 so we may end up tracking different versions with different releases. I don't think there is demand for supporting multiple postcard versions.

[ma2bd]

Hello. I didn't know about the postcard encoding. After reading the specs briefly, it looks like

• integers are encoded in little-endian as LCS and (default) bincode,
• lengths and variant tags are encoded as "varints" which look compatible with the ULEB128 encoding used in LCS.

At this point, I'm only aware of the following differences between postcard and LCS:

• the maximum vector size in postcard is 2^32 - 1 instead of 2^31 - 1 (which won't work in Java, by the way, because Java sizes are signed int32)
• LCS further enforces normalization (aka canonical encoding) for maps and varints.
• LCS further limits the number of traversed containers (aka "container depth") during (de)serialization.
• The LCS/rust runtime is opensource but does not have a crate in crates.io yet (it should have one, hopefully, soon)

Am I missing anything? If not, it seems that it should be rather easy to support (one version of) the postcard runtime in basically all languages (by cloning 2 source files). The only thing is that we should make sure that there is indeed a valid use case. E.g. for security / cryptography applications, I would recommend using LCS instead.

Note that the codegen callbacks into LCS/bincode runtimes are relatively stable now (except maybe method names in Java should eventually switch to snake case). Therefore, it shouldn't matter too much if we support postcard officially in this repo or not.

[mattico]

Yeah, I opened this issue before I started implementing the postcard runtime. Given the similarities between postcard and bincode/lcs (as you noted) it should be easy to support this on all supported languages.

As for using LCS, that's something I hadn't considered. The formats are obviously quite similar, but the supporting library does not support no_std, which is a blocker for me. It would likely be easy to add this support, but I'm happy using a slightly different library that's designed and optimized for my use-case.

I would have no issue maintaining this out-of-tree, I just wanted to upstream it in case it could help someone else.

[ma2bd]

I was just wondering if it wouldn't be less hassle (and possibly beneficial to everyone) to have the Rust no_std implementation of postcard provide an LCS-compatibility mode.

[ma2bd]

For the records, LCS was renamed into BCS ("Binary Canonical Serialization").