> There was a discussion many moons ago about separating the grapher > from the rest. Perhaps you can dig in the archives.
For the sake of others who don't like searching (like myself), I'll pull a Kernel Traffic type summary here. I see that you (Alex) posted about this subject back in August: Alex: http://www.ee.ethz.ch/~slist/rrd-developers/msg00543.html I see that unfortunately it was in response to Tobias himself who seems to have the limited view of rrdtool as being a graphing utility (as opposed to a round robin database storage system, as per its name, with many other potential generic applications): Tobias: http://www.ee.ethz.ch/~slist/rrd-developers/msg00541.html Petri Helenius responded to Tobias as well, pointing out that it would be nice for the existing graphing module in rrdtool to be able to use external data sources (as recently requested on the list w.r.t. some MySQL-stored data): Petri: http://www.ee.ethz.ch/~slist/rrd-developers/msg00542.html Tobias responded to the first post above by Alex, saying that linking the graphing tool seperately shouldn't be a problem because of how modular the code is, but that he didn't see the benefit of doing so as the graphing portion is the heavyweight: Alex: http://www.ee.ethz.ch/~slist/rrd-developers/msg00545.html I see that as being _the_ reason to link it seperately, however, or to at least link the data collection tool seperately (the opposite approach to the same issue) so that it can be used quickly and easily without the graphing portion of the tool. If I may summarize how I see rrdtool as being potentially seperated: 1) A base rrd file library (including inserting, modifying and retrieving data) 2) A data collection / rrd file maintenance tool linked against (1) 3) Perl / other modules that use the above library (1) as well. 4) A graphing tool that creates graphs (in whatever way) using (1) to access the data, but possibly also using other data sources. 5) An rrdtool binary that acts as the current one does, calling the above programs as necessary to do its work. 6) Other data acquisition modules written against (1) or (2) such as converting from MRTG files, accessing SNMP data, etc. As I understand it, this would not be very difficult right now, and I'm not saying anything more than "this is how I think it would be a better overall tool." The issue I believe is the seperation of 'back-end' data handling, 'middle-ware' to make front-ends possible and 'front-ends'. Just my $0.03 ... ;-) -- Michael T. Babcock CTO, FibreSpeed Ltd. http://www.fibrespeed.net/~mbabcock/ -- 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
