Hi Stan,
Glad to see you are interested in development work. I wonder if I might persuade you to take a second look at an idea I've proposed before. As I understand it, you've outlined a proposal to improve RRDtool and create a new front end for it. You think Cricket has some good ideas, but it also has some weaknesses (and I concur). Rather than an entirely new design, could some of your aims be achieved by working with the existing software (RRDTool and Cricket). For example, as we've discussed, the monitor-thresholds implementation in Cricket is inefficient and not very scalable. But if there was an alternative interface to RRDtool update that always returned an array of the most recent CDP values of the lowest resolution RRA, monitoring in Cricket could occur in the same pass as data collection. This could be a significant performance win. I am not certain of the details. There would have to be a mechanism to handle the fact that a CDP is not always generated on an update call. Perhaps returning the last CDP or unknown value (as obtaining the last CDP might require additional disk access during the update pass) or even PDP might work. I've discussed primarily RRDTool details here, but obviously this idea would require some changes to Cricket code as well. I think this would be a great project for someone like you who has a broad perspective spanning RRDTool and Cricket. Why don't I do this myself? Maybe at I some point I will, when I have the time. Well, there's my pitch. Maybe this pitch reflects my work experience in operations. Software developers are always eager to build something new with the latest and greatest. In operations, we usually have to work with what's already there. Jake Jake Brutlag Network Analyst TV Services -- Network Operations Microsoft MSN -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
