[rrd-developers] Re: PIE CHART ??? (long)

[Michael T. Babcock]

> 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:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi