[rrd-developers] Re: rrdtool graph (fwd)

Alex van den Bogaerdt alex at ergens.op.HET.NET
Sun Aug 12 20:41:34 MEST 2001

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.

 / alex at slot.hollandcasino.nl                  alex at ergens.op.het.net \
| 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: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

More information about the rrd-developers mailing list