I know that the event hook thing seems cool, but some caution is in order.
The CVS sensor basically runs on a timer that wakes up once a day, looks at the previous 24 hours of activity, and sends the appropriate hackystat data. Let's call this the "polling" implementation of the sensor.
If the timer associated with a polling sensor fails, (or if we want to install it for the first time), it is easy to handle: you just edit the sensor invocation to look at the previous 48 (or whatever) hours of activity and re-run it.
Let's now consider the case of an event-based (i.e. "interrupt-driven") sensor that runs each time new data is received. As long as it works perfectly, everything is fine. But what happens when the event hook fails for some period of time? What happens if we want to install it into a running subversion server and get old data?
The answer, unfortunately, is that we have to basically implement the equivalent of the polling implementation (i.e. everything except the timer-based wakeup, which is a trival OS-level service).
So, given the choice between implementing both an interrupt-driven and a polling sensor, or just the polling sensor, I suggest for simplicity's sake that we do the latter. Indeed, the polling sensor tends to be easier to implement more efficiently than the interrupt-driven version. The only cost is that we receive the configuration management data at the server the next day, but since Hackystat does not attempt to support real-time notification, that's an acceptable cost.
Cheers, Philip
