Skip to content

Migrate cache to shared repo-cache crate #8

Description

@raiderrobert

Summary

Extract ownrs's custom FileCache into a separate crate inspired by cacache, a content-addressable disk cache (Rust port of npm's cacache).

Current state

Ownrs has a generic FileCache (src/cache/file_cache.rs, ~52 lines) with TTL-based invalidation using file mtime.

But it has no concurrency protection, no integrity verification.

Gaps in current implementation

  • Content dedup : at org scale (2K+ repos), many repos share identical CODEOWNERS or catalog-info.yaml patterns. cacache stores identical content only once.
  • Integrity verification : cacache verifies hashes on every read, protecting against cache corruption on disk.
  • Concurrent access : cacache has a lockless design that handles multiple agents/processes hitting the same cache safely. Ownrs scanning a large org can involve many concurrent fetches.

Notes

The same cache crate could be used by graft and diecut and other tools I've been working on

Ownrs's FileCache is clean and well-designed; its generic serde-based get/set with TTL pattern informed the requirements for the shared crate. The shared crate essentially generalizes this pattern with cacache as the storage backend.

What cacache doesn't do

  • TTL / expiry: no built-in staleness. A thin wrapper checks metadata timestamps. This is the main thing ownrs needs that cacache doesn't provide natively.
  • Structured keys : keys are opaque strings. A wrapper maps structured identifiers to string keys.

Plan

  • Build a shared a new crate inspired by cacache
  • Perhaps look at other tools and how they manage this
  • Do a clean room specification that incorporates structured keys and TTL
  • Make it
  • Migrate ownrs, graft, diecut

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions