I have one application class in the works, to access data from remote systems and store it locally. The class has its own methods to run the query, etc., but inherits from the TimeSeries-Interval class to store and get the data.
When a query is made for data, various metrics are collected on how the query progressed, and this should be written to a log. While the data will conform to some fixed interval, I want the logs to reflect the actual time, and not be restricted to an interval (and dropped if an interval is already stored, etc.).
One approach could be to subclass the TimeSeries.store method as TimeSeries-Interval.store-event or something, but this gets complicated, and is not particularly clean.
Another approach is to define a "log" thinobject inside of the application object, of class TimeSeries. This is consistent with my attempts at implementing an object-oriented system, but it's also a good choice practically. The cost is slight, since the object contains only data, etc., etc.
I needed a syntax for this, and decided to use a single colon to specify a contained object. I added support to the tob.sh script, and it seems to work well.
Assuming no symlinked objects, this query: "tob foo:bar:baz.doit" would resolve to: "tob .foo/.bar/baz.doit". The tob.sh script does this, calling the tob script again as each object hidden directory is resolved, until the query is left with an object.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The above syntax, using ":" to delimit contained objects, seems effective, and was trivial to implement. In the tob.sh thinobject handler/enabler, the object before the colon is accessed, then tob.sh is called again with the contained object explicitly identified, so the final object reference is just an ordinary pathname.
In the perl ThinObject.pm, it was even simpler, hardly even an issue.
Still currently hashing out a project using the thinobject scheme, using TimeSeries ohjects along with application-specific objects, e.g,. a DataLogger class for a particular make & model logger. I have a querylogger method, sufficient to process a query to a remote datalogger, and had inherited from TimeSeries -- so that the datalogger object is also a timeseries object. Effectively, this just means that the datalogger can be used like:
tob ob.new DataLogger
tob ob.querylogger | tob ob.store
ob.get last
It would also, alternatively, be possible for the querylogger method to call the store method directly, internally, but that's sort of what I'm struggling with.
One issue is that I need good conventions and tools for handling the "self" of the object, i.e., sufficient to efficiently call other methods on the object.
But another issue is that simply including a timeseries object inside the datalogger object would also be sufficient, and would work with no changes to the current code base. In that case, I could also (and probably will) have the querylogger method do this internally, but for example:
I have one application class in the works, to access data from remote systems and store it locally. The class has its own methods to run the query, etc., but inherits from the TimeSeries-Interval class to store and get the data.
When a query is made for data, various metrics are collected on how the query progressed, and this should be written to a log. While the data will conform to some fixed interval, I want the logs to reflect the actual time, and not be restricted to an interval (and dropped if an interval is already stored, etc.).
One approach could be to subclass the TimeSeries.store method as TimeSeries-Interval.store-event or something, but this gets complicated, and is not particularly clean.
Another approach is to define a "log" thinobject inside of the application object, of class TimeSeries. This is consistent with my attempts at implementing an object-oriented system, but it's also a good choice practically. The cost is slight, since the object contains only data, etc., etc.
I needed a syntax for this, and decided to use a single colon to specify a contained object. I added support to the tob.sh script, and it seems to work well.
Assuming no symlinked objects, this query: "tob foo:bar:baz.doit" would resolve to: "tob .foo/.bar/baz.doit". The tob.sh script does this, calling the tob script again as each object hidden directory is resolved, until the query is left with an object.
The above syntax, using ":" to delimit contained objects, seems effective, and was trivial to implement. In the tob.sh thinobject handler/enabler, the object before the colon is accessed, then tob.sh is called again with the contained object explicitly identified, so the final object reference is just an ordinary pathname.
In the perl ThinObject.pm, it was even simpler, hardly even an issue.
Still currently hashing out a project using the thinobject scheme, using TimeSeries ohjects along with application-specific objects, e.g,. a DataLogger class for a particular make & model logger. I have a querylogger method, sufficient to process a query to a remote datalogger, and had inherited from TimeSeries -- so that the datalogger object is also a timeseries object. Effectively, this just means that the datalogger can be used like:
tob ob.new DataLogger
tob ob.querylogger | tob ob.store
ob.get last
It would also, alternatively, be possible for the querylogger method to call the store method directly, internally, but that's sort of what I'm struggling with.
One issue is that I need good conventions and tools for handling the "self" of the object, i.e., sufficient to efficiently call other methods on the object.
But another issue is that simply including a timeseries object inside the datalogger object would also be sufficient, and would work with no changes to the current code base. In that case, I could also (and probably will) have the querylogger method do this internally, but for example:
tob ob.new DataLogger
tob ob:raw.new TimeSeries
tob ob:log.new TimeSeries
tob ob.querylogger --log=log.store | tob ob:raw.store
tob ob.get last
tob ob:log.get last
I may really go to town with this containership thing, and it's not at all clear what the reasonable boundaries might be to how far to go.
-- Ken