-
Notifications
You must be signed in to change notification settings - Fork 2
Description
Currently a running server will pick up some types of content changes but not others. For example, if you make an in-place edit to a static file or executable the update will be immediately visible on your website, but if you add a new file or edit a handlebars template you have to restart the server to see the changes. Ideally Operator would notice all types of changes and automatically refresh its internal state (updating indexes, re-compiling templates, etc) on the fly.
Restarting the server isn't a big deal for my use cases, so this issue lower priority for me. It'd be convenient while developing sites, though (it's basically hot reloading).
This needs some design work. Some things to consider:
- What if the changes made the content directory invalid? Should the server self-destruct or just warn and keep its old state?
- How to keep the heavy process of crawling the filesystem and creating the registries/index from bogging down the server? Can this be given a lower priority than request handling?
- How to update the state in a way that doesn't impact in-flight requests?
- Should probably debounce refreshes to avoid churn when users do things like copy a bunch of files into the content directory at once.
If the watching part is problematic or flaky for some reason, an explicit poke could be used to trigger refresh instead (or maybe "as well"). Some other programs (ab)use SIGHUP
for this.