Today Alex van den Bogaerdt wrote: | 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.
that is no problem ... as you know the individual parts of the rrdtool application can be linked standalone at a flick of your finder ... rrdupdate already is, and so is rrdcgi ... the reason for doing that would be faster load time where necessary ... this does not apply for the grapher though as it is the heavy weight itself and thus does not profit from loosing the other parts of rrdtool as they are not big ... but as I said, it does not matter, all function modules of rrdtool are already quite independant fromeach other ... its just a matter of linking them in different ways ... As for snmp, if someone steps up and creates the all dancing, singing snmp data cqusition tool and donetes it to rrdtool, that would be great ... then the frontends could realy concentrate on configuration and presentation ... | | > 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. ok, call them what you like, no problem there ... for me, the fontends are the guys organizing everything on a higher level, defining how to configure a monitoring app with hundreds of targets and presenting everithing in a sensibly organized manner ... having the ability to feed external data to the grapher would certainly bee nice, but this data source must also pass through the massage part of rrdtool this after all makes up a large part of the magic of the grapher, regardles where yor data comes from you do not want to loose this ability ... what we need to get external data into the grapher would be a module which can eat arbitrary time/data pairs and normalize them into a rrdtool data array ... cheers tobi | | -- ______ __ _ /_ __/_ / / (_) Oetiker, ETZ J97, ETH, 8092 Zurich, Switzerland / // _ \/ _ \/ / phoneto:+41(0)1-632-5286 faxto:+41(0)1-632-1517 /_/ \.__/_.__/_/ mailto:[EMAIL PROTECTED] http://people.ee.ethz.ch/~oetiker -- 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
