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
In terms of abscissa, how would a good implementation for hooks look like. Currently, we are implementing it without really using a lot of abscissa itself, and I would like to understand, if using the framework a better design is possible.
So essentially, we have a Hooks struct that users can define in a configuration (we have global hooks [run application level], repository hooks [run, when accessing a repo], backup hooks [run during backup command lifecycle] backup.snapshots.hooks [run when creating/finishing a snapshot during a backup], src: https://github.com/rustic-rs/rustic/blob/f565eea1f6cb2d9bd9d0f2d324c0d673ccaf7a3a/config/hooks.toml) and execute commands during the application lifecycle.
For this, we essentially call Hooks::use_with(|| -> Result<T> {}) within a command, we also run global hooks inside the Application::after_config method, final hooks we run in Application::shutdown_with_exitcode methods. I think it would be interested, to integrate this functionality a bit deeper in the framework, because it feels like this would give more control over the application's lifecycle and make it easier to integrate.
As the creator of this framework, @tony-iqlusion, is there some insights you could give how to do that better? Would it be more straight forward, to use something like a Component for that, that the commands would be run in, like the abscissa_tokio component essentially?
Or do you think, the scope of this is too wide? Essentially from the most outer scope, begin and end of application, with complete error handling, then on command level and even within a command when accessing certain parts within a custom type?
The text was updated successfully, but these errors were encountered:
In terms of
abscissa
, how would a good implementation for hooks look like. Currently, we are implementing it without really using a lot of abscissa itself, and I would like to understand, if using the framework a better design is possible.I would contribute that implementation then to the framework. Currently, we are implementing it like this: https://github.com/rustic-rs/rustic/blob/f565eea1f6cb2d9bd9d0f2d324c0d673ccaf7a3a/src/config/hooks.rs
So essentially, we have a
Hooks
struct that users can define in a configuration (we have global hooks [run application level], repository hooks [run, when accessing a repo], backup hooks [run during backup command lifecycle] backup.snapshots.hooks [run when creating/finishing a snapshot during a backup], src: https://github.com/rustic-rs/rustic/blob/f565eea1f6cb2d9bd9d0f2d324c0d673ccaf7a3a/config/hooks.toml) and execute commands during the application lifecycle.For this, we essentially call
Hooks::use_with(|| -> Result<T> {})
within a command, we also run global hooks inside theApplication::after_config
method, final hooks we run inApplication::shutdown_with_exitcode
methods. I think it would be interested, to integrate this functionality a bit deeper in the framework, because it feels like this would give more control over the application's lifecycle and make it easier to integrate.As the creator of this framework, @tony-iqlusion, is there some insights you could give how to do that better? Would it be more straight forward, to use something like a
Component
for that, that the commands would be run in, like theabscissa_tokio
component essentially?Or do you think, the scope of this is too wide? Essentially from the most outer scope, begin and end of application, with complete error handling, then on command level and even within a command when accessing certain parts within a custom type?
The text was updated successfully, but these errors were encountered: