[PEAK] Re: Proposal for another Wiki "tutorial"

[Phillip J. Eby]

At 02:27 PM 7/16/04 -0700, John Landahl wrote:

>I'm thinking of using an events.Task for each test runner (e.g. test HTTP
>connectivity for system abc.xyz.com every 2 minutes), which would allow
>peak.events to do all the scheduling.

After some more thought, it occurred to me that the "pull" model I gave 
isn't the best one for the core operation of the system.  Instead, it will 
generally be more useful to have a function like 
'measurement_occurred(measurement)', where a measurement knows its object 
of care, metric type, units, etc.  Then, test runners like you mention 
simply call measurement_occurred() to publish their results.

Appropriate hooks into measurement_occurred can then compute derived or 
summary metrics, log data, store it in a database or cache, etc.

Then, a *separate* pull API can retrieve it from the DB or cache in order 
to do reporting.

In other words, both push and pull should exist in the core, as some 
facilities will be of each type.