Eric Rakestraw
0cc2862170
feedkit now contains a reusable core, while weatherfeeder is a concrete implementation that includes weather-specific functions.
2.0 KiB
Naming Conventions
This document defines naming conventions for the Feed-based ingestion daemons and shared libraries in the HomeOps ecosystem.
These conventions are intentionally simple and consistent, and are designed to make system behavior obvious from names alone.
Core Shared Module
Module / repository name maximumdirect.net/feedkit
Purpose
feedkit provides the domain-agnostic core used by all feed-processing daemons:
polling, scheduling, filtering, routing, persistence fanout, and signaling.
It contains infrastructure primitives, not domain logic.
Feed Daemons
Naming Format
feeder
This name is used for both:
- the repository / Go module name
- the compiled binary name
Rationale
A feeder is an active agent that:
- consumes one or more upstream feeds
- normalizes new items into events
- emits facts and/or signals into the system
Examples
| Domain | Repository / Binary |
|---|---|
| Weather | weatherfeeder |
| RSS | rssfeeder |
| News | newsfeeder |
| NBA | nbafeeder |
| Earthquakes | earthquakefeeder |
| Patreon | patreonfeeder |
Non-Feed Daemons
Daemons that perform downstream work (downloads, archiving, transformation, etc.)
should not use the feeder suffix.
Preferred naming reflects the primary action:
mediafetchervideodownloaderarchiversyncd
This preserves a clear semantic boundary between:
- feed detection (feeders)
- work execution (workers)
Go Naming Conventions
- All repository, module, package, and binary names are lowercase
- No dashes (
-) or underscores (_) in Go package names - Repository name and binary name should match unless there is a compelling reason not to
Summary
- Core library:
feedkit - Feed daemons:
<domain>feeder - Downstream workers: action-based names
- Names should communicate role, not implementation details