User configuration caching #22

New issue

Open

opened 2026-08-25 03:53:59 +00:00 by crumbcake · 1 comment

crumbcake commented

2026-08-25 03:53:59 +00:00

Owner

The current implementation of user configuration files involves recursively scanning each level of the file system for .dav_config.yaml files, parsing each of them, and then combining into a single final object. This process must be repeated for every web request and its complexity expands with the number of directories and configuration entries present.

An ideal cache implementation will utilize file modification times and/or inotify events for invalidation.

The current implementation of user configuration files involves recursively scanning each level of the file system for `.dav_config.yaml` files, parsing each of them, and then combining into a single final object. This process must be repeated for every web request and its complexity expands with the number of directories and configuration entries present. An ideal cache implementation will utilize file modification times and/or `inotify` events for invalidation.

crumbcake added the

labels

2026-08-25 03:53:59 +00:00

crumbcake self-assigned this

2026-08-25 03:53:59 +00:00

crumbcake changed title from ~~User configuration file caching~~ to User configuration caching

2026-08-26 14:34:43 +00:00

crumbcake commented

2026-08-26 14:39:58 +00:00

Author

Owner

When the configuration for any child is being resolved we only need to walk up the tree until we find an up-to-date node and overlay the child's configuration on top of it.

When the system detects that a configuration file has been modified, all it needs to do is delete the corresponding node from the graph, forcing any future query to recompute the configuration.

The general theory of operation here is to treat the configuration as a directed acyclic graph where each node represents a directory (or file if future changes to the configuration system add file-level options) and contains the computed value of all its parents combined into a single object. When the configuration for any child is being resolved we only need to walk up the tree until we find an up-to-date node and overlay the child's configuration on top of it. When the system detects that a configuration file has been modified, all it needs to do is delete the corresponding node from the graph, forcing any future query to recompute the configuration.