Trait TotalOrderLog

Source

pub trait TotalOrderLog<V>: Protocol<Note = Note> {
    // Required methods
    fn append(value: V) -> Self::Cmd;
    fn read(from: Position) -> Self::Cmd;
    fn classify(ind: Self::Ind) -> LogInd<V>;
}

Expand description

What a layer above a totally ordered log may depend on, and the whole of what it may.

V is the value a client appends. An implementation is free to wrap it — both of the ones here carry the originator alongside — which is why TotalOrderLog::append builds the request rather than the caller constructing one, and why TotalOrderLog::classify takes the value back out.

Satisfying the port is a decision, not an accident of shape. link.rs records an earlier draft making its port a blanket impl over every protocol with the right associated types, which meant a protocol became a link by coincidence; a log says so. One that has not is rejected when the project is built:

fn requires_a_log<L: recon_protocols::total_order_log::TotalOrderLog<u32>>() {}
requires_a_log::<NotALog>();

Required Methods§

Source

fn append(value: V) -> Self::Cmd

The request that appends value to the log.

A constructor rather than a fixed type, because the request is the implementation’s own vocabulary.

Source

fn read(from: Position) -> Self::Cmd

The request that reads the ordered sequence from from onwards.

The departure this module’s header records. Served locally, so it may lag an append that has completed elsewhere.

Source

fn classify(ind: Self::Ind) -> LogInd<V>

What this indication means to the layer above.

Total, as crate::link::Link::classify and crate::detector::Detector::classify are: a layer above maps its child’s indications with one function, so an implementation that could report something unclassifiable would leave that layer with a case it could only drop — and silently absorbing something is this project’s cardinal sin.