Skip to main content

Crate io_m2dir

Crate io_m2dir 

Source
Expand description

§io-m2dir

I/O-free m2dir coroutines: every filesystem exchange needed to deliver, read, flag and remove messages in the m2dir mail storage format is a resumable state machine emitting filesystem requests instead of performing I/O itself, so the caller owns the syscalls and pumps the coroutine (see the client feature for a ready-made std-blocking pump).

The crate ships two of the standard Pimalaya layers: the I/O-free coroutines (no_std core, always present) and a std-blocking client (client feature, default) backed by std::fs. There is no full client layer: m2dir is local storage, so there is no socket to open.

§Layout

The source tree groups coroutines by the object they act on, one folder per object with a sibling module carrying the shared types: m2dir (create, delete, list a mailbox directory, plus the m2dir::M2dir handle), entry (store, get, list, delete a message, plus entry::M2dirEntry) and flag (add, remove, set flags, plus flag::M2dirFlags). Code reused across objects lives at the crate root: the coroutine contract, the M2dirStore root wrapper, the M2dirPath newtype and the private checksum helpers. The std client spans every object.

§The coroutine contract

Every coroutine implements coroutine::M2dirCoroutine, mirroring the shape of core::ops::Coroutine: a resume step returns a coroutine::M2dirCoroutineState, either a yield or the terminal result. io-m2dir is filesystem-flavoured, so every coroutine picks the shared coroutine::M2dirYield, which gathers every primitive the crate emits: directory create, read and remove; file create, read, exists and remove; path rename; and the process id and random bytes needed to mint entry identifiers. The caller services each yield and feeds the matching coroutine::M2dirArg back on the next resume.

§The std client

client::M2dirClient (client feature) wraps a filesystem root pointing at an m2store and exposes one method per coroutine, running each to completion against std::fs. It supplies the process id and a xorshift64* random nonce the coroutines ask for, and adds a thread-scoped parallel bulk read for reading many entries at once.

§Conventions

The conventions every Pimalaya repository shares (the sans-I/O coroutine approach, no_std, module and naming rules) are described in the Pimalaya ARCHITECTURE and GUIDELINES. Public types follow the M2dir-Target-Verb naming scheme (M2dirEntryStore, M2dirFlagAdd) with Options, Output and Error companions. Runnable snippets live in each coroutine module’s rustdoc, and the integration test exercises the full client surface.

Modules§

clientclient
Standard, blocking m2dir client
coroutine
Generator-shape coroutine contract
entry
Entry-level m2dir coroutines and their shared types.
flag
Flag-level m2dir coroutines and their shared type.
m2dir
M2dir-level coroutines and their shared type.
path
‘/’-separated path used by m2dir and m2store.
store
Root m2store directory containing one or more m2dirs.