Hello and questions..

[Adrian Wilkins]

On 03/07/14 12:26, Joachim Breitner wrote:
> Hi,
>
>

>> I'm envisaging a program that goes through your calendar and adds
>> entries
>
> Right. And this program can be technically completely independent from
> arbtt, in the spirit of Unix and its small dedicated tools.
>

Indeed. This puts me in mind of an alternate approach - a program (or 
more than one) that arbtt-capture interrogates for event data ; so you 
could have arbtt-meeting-daemon etc, and arbtt-capture could add their 
information to it's TimeEventLog entries.

But I still like the idea of being able to work with multiple logs, if 
only because I could write the meeting log thing at the end of the month 
and be able to retrospectively include the events in my arbtt-stats run 
- in much the same way that you can write new rules and get a better 
quality report from the same logged events.

>>   If you could aggregate logs, programs
>> that served as alternate event sources would just naturally feed into
>> that feature.
>
> Sorry, I can’t follow. How is that related to aggregating logs?
>

I was thinking that in order for the separate program(s) discussed above 
to produce useful inputs for arbtt-stats, it would have to aggregrate 
the data in those logs together such that all events for a given sample 
are considered part of the same TimeLogEntry (when being categorized).

e.g. for the hypothetical meeting analyzer program, if it produces a 
TimeLogEntry for each minute of your meeting, you wouldn't want to 
consider those separately to the other TimeLogEntry objects logged by 
arbtt-capture (I take my laptop to meetings and the activity logged 
would disagree with the meeting category in some cases).

----  meeting-analyzer log
2014-07-03 12:32:00 Meeting:$title="Meeting about tortoises"
----  arbtt-capture log
2014-07-03 12:32:05 Program:$title="Web browser : page about snakes"

Rule sets that considered Meeting to take priority over everything else 
would still put the second log entry in the "Project:Snakes" category 
rather than the "Project:Tortoises" category, because that entry has no 
Meeting.

If you rolled those two entries together based on their time being close 
to each other, then Meeting can override the web browser. I'm presuming 
here that arbtt-stats analyzes each TimeLogEntry separately.