Tobias Oetiker wrote: > | Just as getting the numbers (snmp) is related to (but not built in to) > | rrdtool update, generating the graph should be related to rrdtool fetch.
> | rrdtool fetch could deliver the data in ascii format (and hopefully > | formatted to the users liking) or in binary format. Just use a portion > | of the current rrdtool graph script language: > Here I do not agree with you. Everybody (almost) who uses > rrdtool needs the graphing part, so it makes no sense complicating > everybodies lives by breaking it out of rrdtool into a seperate > application. Sure, however also (almost) everybody needs to collect their data using snmp and feed this to rrdtool update. I don't think that should go into rrdtool and in a similar way I try to make a point that the grapher itself shouldn't be part of the executable. This doesn't mean that it shouldn't be part of the package. My goal is not to eliminate the grapher portion from the rrdtool package, I'm merely suggesting it should not be integrated as tightly as it is now inside the back-end part. > Also interfacing to fetch via ascii buyes us nothing > except making things slower ... This is not what I ment. rrdtool fetch should either return the data in an ascii format (to the user, like rrdtool fetch does now) or in a binary format (like rrd_fetch_fn() does). So, I'm suggesting that it should also be possible to return in a binary format, not that it should only work in a ascii-format. > I do agree that other parts of rrdtool can and will profit from > having the data massaging facilities available in a module separate > from rrdtool graph, but at the same moment I do not see why this > would require rrdtool graph and a potential rrdtool report to be > removed from the main body of the application ... The concept of separate front-end and back-end applications sort of dictates this. For one it would make it possible to use the grapher part with another back-end, making the oracle fans happy. Generating a stream of numbers out of the RRAs is clearly a task for a back-end (rrdtool). Processing these numbers in whatever format you like (be it a text-report or an image) is something that falls in another catagory, namely front-end. This all of course being MHO and mine alone. -- __________________________________________________________________ / [EMAIL PROTECTED] [EMAIL PROTECTED] \ | work private | | My employer is capable of speaking therefore I speak only for myself | +----------------------------------------------------------------------+ | Technical questions sent directly to me will be nuked. Use the list. | +----------------------------------------------------------------------+ | http://faq.mrtg.org/ | | http://rrdtool.eu.org --> tutorial | +----------------------------------------------------------------------+ -- 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
