-
Notifications
You must be signed in to change notification settings - Fork 0
Architecture Overview
libsavesync is structured in six layers, each with a clearly defined responsibility.
Dual entry points: a linkable C ABI (static/shared library) and a standalone binary exposing the same operations over an IPC protocol. Both are thin wrappers over the same internal core — this is a communication layer, not a logic duplication. ABI stability rules apply from the very first shipped version.
→ See Layer-1-Interface
sv_register() creates a new registration from a live_save_path plus optional metadata. Produces an opaque handle and a persistent 8-character unique ID. In STRATEGY mode, identity resolution (tiered serial/checksum/hash-DB) and manifest-driven path/shape strategy apply; in DEFAULT mode, it's a bare, generic file/folder tracker.
sv_register_with_manifest() accepts an optional sv_manifest_t that drives identity resolution at registration time. The manifest specifies the identity method (serial extraction, checksum, or pluggable callback), file/offset/pattern parameters, and platform metadata.
→ See Layer-2-Registration-and-Identity
A small local file/record store, one entry per registration and one per magazine entry. Carries a file-level schema_version so future field additions can be migrated rather than breaking existing stores. Designed to stay tiny — this is metadata, not save content.
→ See Layer-3-Metadata-Store
Atomic copy-out from live save into a new magazine entry (save), and atomic copy-in from magazine to live save (pull/pull_select). Includes listing, inspection, reparenting, and deletion operations. Conflict-checked by default — never clobbers without explicit override.
→ See Layer-4-Local-Save-and-Pull
Runs automatically as the final step of every successful sv_save(). FIFO eviction: oldest entry under that specific registration is deleted once retention_count is exceeded. Orphaned entries are outside any registration's cap and are never auto-evicted.
→ See Layer-5-Retention-and-Rotation
The core stays networking-free. A transport is a struct of two nullable function pointers (push/pull). sv_push_external() sends one specific magazine entry out. sv_pull_external() fetches a remote save into a new local magazine entry — it never writes directly to the live path.
→ See Layer-6-External-Transport
See also: Philosophy | API-Reference
libsavesync Wiki