Rindle docs and package mapSkip to main content

Crate rindle_wire

Crate rindle_wire 

Source
Expand description

§rindle-wire — the normalized subscription protocol

The wire vocabulary of Rindle Realtime’s “both wires, one protocol” rule (RINDLE-REALTIME-DESIGN.md thesis + §4): the same normalized subscription is spoken client←room and room←rindled, so its types live in one crate that every party depends on — the native daemons (rindle-replica, rindle-server) on the emit side, the room (rindle-room-core) on both sides, and, twinned in TypeScript, @rindle/remote on the client. Three layers, one per module:

Beside the frame layers sits query_key — the canonical query identity every materialization map dedups by (rindled’s manager and the room’s materialize-on-presentation), so both ends of a wire agree on “the same query” — and family_key, the same construction over a query’s template (its root equality literals punched into holes), which is how the daemon recognizes the V subscriptions that differ only in a literal as one parameterized query family (design 310).

This crate must stay wasm-clean — the same discipline as the root rindle crate: std-only, no C-toolchain/SQLite deps, no threads. And it holds no transport: sockets and IO belong to the hosts (rindle-server, the Node shell, the DO). The gate is cargo check -p rindle-wire --target wasm32-unknown-unknown; keep it green.

Modules§

family_key
FamilyKey — the identity of a parameterized query family (design 310 §3): the QueryKey construction over a query’s template, the canonical AST with its eligible root-equality literals punched into holes. Two subscriptions are family-mates iff their FamilyKeys are equal; the extracted literal tuple — the Binding, a [CanonKey] — is what distinguishes them.
normalize
Normalized change events — the second serializer beside the engine’s flat path (rindle::flatten), for a local-first client that runs its own normalized base tables + local IVM.
normalize_protocol
The normalized subscription protocol (NORMALIZED-CHANGES-DESIGN.md §3) — the path-free twin of the engine’s flat_protocol. The envelope semantics are identical (a once-per-subscription NormalizedHello, a logical-seq-0 snapshot, then gap-free incremental NormalizedBatches at seq 1, 2, …); only the payload differs — table-tagged NormalizedOps instead of path-tagged FlatChanges — and the hello is slimmer: flat per-table schemas (for positional-row alignment + a normalized_fp), not a nested hierarchical view schema (§3).
query_key
QueryKey — the canonical identity of a subscription query, the dedup key of every materialization map (rindled’s MaterializationManager and the room’s materialize-on-presentation bookkeeping, RINDLE-REALTIME-DESIGN.md §4/§10.1). Two subscribers share one materialized pipeline iff their keys are equal; the fingerprint_hex form is the queryKey string that crosses the control planes. Moved here from rindle-server so the daemon and the room compute identical keys by construction.
wire_json
The normalized protocol’s JSON wire rendering — byte-for-byte the shape the @rindle/remote client validates (bare cells, camelCase keys, lowercase op tags, hex fingerprints, f64-safe counters). Moved here from rindle-replica so every party on the wire shares ONE codec: the napi addon and the Rust daemon’s ws front emit with it (via rindle-replica’s re-export), and the room — the first Rust consumer of these frames (RINDLE-REALTIME-DESIGN.md §3) — parses with it. The ..._from_json decoders are new with the room’s upstream leg; until they landed, decode existed only in TS (@rindle/remote/src/normalized.ts).