Proposed configuration layout

[sdenike]

In regard to the discussion that took place in #14, I think breaking the config file out into per-user configurations would help keep things cleaner long-term and allow for future growth—especially for users who want to add calendars without needing to understand Docker or touch a large shared config file.

The idea would be to still support a main/default config for higher-level settings, but allow individual user configs to live in their own directories and be merged at runtime.

Proposed layout

├── shelby/
│   ├── sports.yml     # Optional: split configs by purpose
│   └── config.yml     # Optional: single large per-user config
├── johannes/
│   └── config.yml
├── nicole/
│   └── config.yml
└── defaults.yml       # Optional global defaults

Each subdirectory represents a user (or logical grouping), and any .yml file within it is parsed and loaded. This allows users to either keep one large config or break things down into smaller, purpose-specific files. Which I think having things be more granular will help people keep their configs in order.

URL namespace example

To avoid name collisions between calendars, output URLs could be namespaced based on the directory name, for example:

https://calunite/shelby/sports.ics

Parsing behavior (high-level)
• Scan /data
• Load defaults.yml (if present)
• Recursively scan subdirectories
• Parse all .yml files found
• Merge configs, applying defaults where values are not defined

Optional future enhancement

Each config file could optionally define its own update interval. If not specified, it would fall back to the global default (e.g., Docker Compose or defaults.yml). This would allow rarely changing calendars to refresh daily or less often, while more dynamic calendars could update more frequently—reducing unnecessary processing and network requests and keeping all users calendars updated properly.

And yes I totally ran it through ChatGPT to clean up my thought process and make it look pretty 😉