Expand description
Interfaces to implement and compose event processors on top of data streams with some p2panda implementations out-of-the-box, wrapping existing p2panda crates for causal message ordering, log validation, access control and group encryption CRDTs which might come in handy for some peer-to-peer applications.
Developers can “stack up” different stream processors on top of each other and layer them based
on the application’s needs. Each processor will formulate requirements (in the form of a Rust
trait) to the underlying data type; you either “bring your own” or use our Operation data type
which has most requirements implemented.
In p2panda we clearly separate the “event delivery” layer from the “event processing” one. This part of the stack doesn’t care what transport was used (pidgeon carriers, usb sticks, internet protocol, LoRa, etc.). Ideally the application should just work fine independent of how the data was delivered, the only part which really matters is how the event stream was processed.
This stream processor design can be nicely combined with a Pub/Sub system (like p2panda-net),
scoped and stateful stream controllers (in p2panda Node API) and storage backends supporting
atomic transactions (p2panda-store).
§Single-Threaded Design
Processors are meant to only be executed within a single thread and do not allow Send or
Sync types. Users need to make sure to run this code in a “local” tokio runtime.
Modules§
- ingest
- Checks an incoming operation for log integrity and persists it into the store when valid.
- log_
prune - Coordinates pruning of a log’s prefix based on a prune flag.
- orderer
- Causal / partial order over a set of items which form a dependency graph.
Structs§
Enums§
Traits§
- Processor
- Interface for implementing data processors.
- Processor
Ext - Extension trait for
Processorthat provides convenient methods forStreamprocessing. - Stream
Layer Ext - Extension trait for
Streamthat provides convenient methods to layer up processors.