You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
mkantor
changed the title
Live websites should reflect changes to the content directory
Websites should reflect changes to the content directory without a restart
Sep 3, 2020
Once the server is initialized, spin off a background thread to watch for filesystem changes (maybe using notify?).
React to any changes (with some debounce) by creating a new ContentDirectory, then using that to create a new FilesystemBasedContentEngine. Give this whole process a low priority somehow.
Since the engine is already wrapped in an Arc<RwLock<T>>, it should be possible to obtain a write lock and then atomically swap in the new engine (I hope?). This needs to be cheap/fast.
Needs more thought/prototyping.
mkantor
changed the title
Websites should reflect changes to the content directory without a restart
Websites should reflect content changes without a restart
Sep 3, 2020
mkantor
changed the title
Websites should reflect content changes without a restart
Websites should reflect content changes without a server restart
Sep 3, 2020
mkantor
changed the title
Websites should reflect content changes without a server restart
Websites should reflect all content changes without a server restart
Oct 1, 2020
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:
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.The text was updated successfully, but these errors were encountered: