2 releases

new 0.1.1 Nov 12, 2024
0.1.0 Jul 23, 2024

#1519 in Embedded development

Download history 9/week @ 2024-07-29 7/week @ 2024-08-12 3/week @ 2024-08-19 12/week @ 2024-08-26 3/week @ 2024-09-09 24/week @ 2024-09-16 25/week @ 2024-09-23 18/week @ 2024-09-30 3/week @ 2024-10-21 130/week @ 2024-11-11

133 downloads per month
Used in 7 crates (2 directly)

Apache-2.0

60KB
1.5K SLoC

Wasefire wire format.

This crate provides a binary format for a wire used as an RPC from a large host to a small device. The format is compact and canonical, in particular it is not self-describing. Compatibility is encoded with tags of a top-level enum, in particular RPC messages are never changed but instead duplicated to a new variant. The host supports all variants because it is not constrained. The device only supports the latest versions to minimize binary footprint. The host and the device are written in Rust, so wire types are defined in Rust. The data model is simple and contains builtin types, arrays, slices, structs, enums, and supports recursion.

Alternatives like serde (with postcard) or protocol buffers solve a more general problem than this use-case. The main differences are:

  • Not self-describing: the model is simpler and more robust (smaller code footprint on device).
  • No special cases for options and maps: those are encoded from basic types.
  • No need for tagged and optional fields: full messages are versioned.
  • Variant tags can be explicit, and thus feature-gated to reduce device code size.
  • Wire types are only used to represent wire data, they are not used as regular data types.
  • Wire types only borrow from the wire, and do so in a covariant way.
  • Wire types can be inspected programmatically for unit testing.
  • Users can't implement the wire trait: they can only derive it.

Dependencies

~220–660KB
~15K SLoC