Ken Irving - 2007-01-25

With this system still in development, I've got some data coming in and being stored in a TimeSeries object, which data includes several sensor values.  The next step will be to parse this into individual values, or I suppose, datum objects, which inherit from (or contain) the TimeSeries class.  For sensor values which change continuously, we'll be storing a timeseries of sampled values.

But some of the incoming data represents constants or "settings" from the target system, e.g., which might control some aspect of the application.  These values rarely (if ever) change, so storing the same value as a timeseries wouldn't make much sense.  On the other hand, the TimeSeries class provides useful machinery for managing the storage of these things, along with a timestamp.  I think the solution will be to subclass TimeSeries to, perhaps, TimeSeries-Setting or something.

TimeSeries-Setting would have store and get methods.  The store method would compare the provided value (datum?) against the last one stored, and then NOT store it if unchanged.  The get method would compare the target timestamp(s) and then infer the value based on the stored information.

Optionally, the attempt to store an unchanged value might be logged, or might be just ignored.  This choice might depend on the application.

A better name would likely be needed.  The "setting" moniker would maybe better be derived from a Datum class, subclassing TimeSeries, or subclassing a more generically-named class.  Perhaps TimeSeries-Sparse?