The simple backend only saves the last value of each device. The redis backend can save historical data until the system runs out of memory. Any future backend will also be saving an unbounded amount of data.
The Solution
This issue proposes we add a parameter to the driver configuration, max_history. This property will be an integer and represents the number of historical entries that will be saved for that driver instance (all devices created by that driver instance will have the same history size limit.) If there are more than this number of entries, the oldest ones will be dropped.
This would make the driver provide history size information to the backend so, at most, 1000 entries will be saved (in this example.)
This parameter will be ignored by the simple backend, since it can only save one entry. Redis has built-in support for capping the total number of saved entries, so we'll leverage that feature.
"Good First Issue" Help
This is fairly straight forward, even though it requires changes in several crates:
The drmem-config crate needs the max_history field added to the driver configuration structure.
The two "register device" functions need another parameter (an Option<usize>?) to specify the history size.
The redis backend crate needs its mk_report_func method modified to send the correct redis command option to maintain the history size.
Tests should be written to make sure the proper redis command is sent.
I'm sure I'm missing some details, but that should be enough to get the compiler to point out the other spots that need to be fixed.
The Problem
The simple backend only saves the last value of each device. The redis backend can save historical data until the system runs out of memory. Any future backend will also be saving an unbounded amount of data.
The Solution
This issue proposes we add a parameter to the driver configuration,
max_history
. This property will be an integer and represents the number of historical entries that will be saved for that driver instance (all devices created by that driver instance will have the same history size limit.) If there are more than this number of entries, the oldest ones will be dropped.For instance:
This would make the driver provide history size information to the backend so, at most, 1000 entries will be saved (in this example.)
This parameter will be ignored by the simple backend, since it can only save one entry. Redis has built-in support for capping the total number of saved entries, so we'll leverage that feature.
"Good First Issue" Help
This is fairly straight forward, even though it requires changes in several crates:
drmem-config
crate needs themax_history
field added to the driver configuration structure.Option<usize>
?) to specify the history size.mk_report_func
method modified to send the correct redis command option to maintain the history size.I'm sure I'm missing some details, but that should be enough to get the compiler to point out the other spots that need to be fixed.