p2panda_stream/lib.rs
1// SPDX-License-Identifier: MIT OR Apache-2.0
2
3//! Interfaces to implement and compose event processors on top of data streams with some p2panda
4//! implementations out-of-the-box, wrapping existing p2panda crates for causal message ordering,
5//! log validation, access control and group encryption CRDTs which might come in handy for some
6//! peer-to-peer applications.
7//!
8//! Developers can "stack up" different stream processors on top of each other and layer them based
9//! on the application's needs. Each processor will formulate requirements (in the form of a Rust
10//! trait) to the underlying data type; you either "bring your own" or use our `Operation` data type
11//! which has most requirements implemented.
12//!
13//! In p2panda we clearly separate the "event delivery" layer from the "event processing" one. This
14//! part of the stack doesn't care what transport was used (pidgeon carriers, usb sticks, internet
15//! protocol, LoRa, etc.). Ideally the application should just work fine independent of how the data
16//! was delivered, the only part which really matters is how the event stream was _processed_.
17//!
18//! This stream processor design can be nicely combined with a Pub/Sub system (like `p2panda-net`),
19//! scoped and stateful stream controllers (in `p2panda` Node API) and storage backends supporting
20//! atomic transactions (`p2panda-store`).
21//!
22//! ## Single-Threaded Design
23//!
24//! Processors are meant to only be executed within a single thread and do not allow `Send` or
25//! `Sync` types. Users need to make sure to run this code in a "local" tokio runtime.
26#[cfg(feature = "ingest")]
27pub mod ingest;
28#[cfg(feature = "log_prune")]
29pub mod log_prune;
30#[cfg(feature = "orderer")]
31pub mod orderer;
32mod processors;
33#[cfg(test)]
34mod test_utils;
35
36pub use processors::*;