Bvckup | Version 2
A rework of the loggging module, coming up in Release 73.
As you may or may not know, Bvckup 2 uses a dual-module architecture of the inside.
One module is the backup
. It maintains the list of backup jobs, schedules, executes backups and generally does other useful things that don't require direct user involvement.
The second module is the
. This is the part that displays the app's window and allows users to monitor and control whatever the engine module is doing.
The principal point is that the engine and the UI are
from each other. They share no run-time data and communicate with each other using a messaging protocol.
This isolation is what enables the app to run in
. In this mode the engine runs in its own process, as a system service, and the UI runs as a regular desktop app.
It was all well and beautiful, but there was, however, a
The caveat was the
Logs are inherently shared data - they are written by the engine and they are read and displayed by the UI. Logs tend to be bulky, so it is shared app data of a special kind and it requires special handling.
Prior to R73 the app included a third module (in its dual-module architecture, no less) - the log manager. It was a complicated contraption that abstracted log access for the engine and the UI, and the biggest issue with it was that it behaved completely differently depending on which mode the app was in.
In desktop mode, the manager was writing *and*
logs on behalf of the engine and the UI was merely displaying them. However, in service mode, the engine did no indexing, just the writing, while the UI was making copies of all logs for its own use and then it was indexing *them*.
This is exactly the kind of non-uniform conditional processing that the dual-module design was meant to avoid!
The separate logging module is no more. The engine no longer does any log indexing, it is now entirely the UI's reponsibility. Indexes can now be rebuilt on demand at any time, and finally, the UI no longer creates its own copies of the log files. Instead, it works with the engine to gain access to the engine's copy of the logs, using
to move open file handles across the process boundary when needed.
The UI now can display logs while it is still catching up with them.
Think -- running in service mode and launching the UI only once a week. On each launch the UI needs to index a week's worth of log entries it hasn't seen before. Prior to R73, the UI would just sit there and show "synching ... XX% done". Now the sync is done in the background (as per the screenshot).
The UI now can also recover gracefully from indexes getting corrupted (e.g. due to a cold power cycle or blue screen).
Just as important, the underlying code is now much simpler, lighter and more uniform, the executable is 8KB smaller and the developer is generally happier. Good news all around.
Back to the /wip index