[rrd-developers] rrdtool and object-orientation
Martin Sperl
rrdtool at martin.sperl.org
Tue Mar 6 16:40:50 CET 2012
Hi!
After some discussions with Tobi here an initiative for a broader discussion regarding how to make rrdtool more object orientated.
Maybe first a reason why I am starting this:
I initially started with the idea of implementing different types of graphs - scatter graphs that could get used for correlation of CPU versus TPS or similar to estimate the capacity reserves (See the P.s. for a quick overview what I would like to achieve)
So this would require some changes to the argument parser as well and now after having started with a key-value parser that still does the positional arguments as well I am now getting closer to the point of graphing.
But then while writing the new parser I came to realize that we are carrying a lot of stuff arround that is either not needed (lots of fields in graph_desc_t) and now that I am finally getting closer to adding new types it came to my mind to take the opportunity to also improve the code by converting(the graphing code) to a more object-orientated approach at the same time.
I have been thinking about different options and would like your thoughts of in which directions we should go:
* do an OO approach of our own (maybe following the ideas of: http://www.planetpdf.com/codecuts/pdfs/ooc.pdf)
* using GLIB (with class and interface type), which requires a lot of boilerblade code to get written per class
* using GLIB with a preprocessor like gop2 or Vala
* going with c++
* other options (how do pango and others do it?)
The idea is really to make the code easier to maintain and better localized the code to what is really needed.
THis should also make extending it with new functionality much easier (maybe even allowing for dynamic loading of functions?)
So please share your input on the direction we should be taking here...
Obviously all this would be material possibly for a 2.0 release.
Thanks,
Martin
P.s: What in the end my goal would be is configuring a graph like this:
title
XAXIS2 XAXIS3
+----------+----------+
| | | Y
Y | | | A
A | | | X
X | | | 4
3 | +----------+
| | XAXIS3
+----------+----------+
| |
Y | | Y
A | | A
X | | X
1 | | 2
| |
+---------------------+
XAXIS1
legend
VDEF:p95=data2,95,PERCENTNAN
AXIS:xaxis=1:label=XAXIS1:min=AUTOSCALEMIN:max=AUTOSCALEMAX:type=TIME
AXIS:xaxis=2:label=XAXIS2:min=AUTOSCALEMIN:max=AUTOSCALEMAX:type=TIME
AXIS:xaxis=3:label=XAXISx:min=AUTOSCALEMIN:max=AUTOSCALEMAX:type=TIME
AXIS:yaxis=1:label=YAX1:min=AUTOSCALEALTMIN:max=AUTOSCALEALTMAX:type=VALUE
AXIS:yaxis=2:label=YAX2:min=AUTOSCALEMIN:max=P95:type=VALUE
AXIS:yaxis=3:label=YAX3:min=AUTOSCALEMIN:max=AUTOSCALEMAX:type=VALUE
AXIS:yaxis=4:label=YAX4:min=AUTOSCALEMIN:max=AUTOSCALEMAX:type=VALUE
AXIS:yaxis=5:label=YAX5:min=AUTOSCALEMIN:max=AUTOSCALEMAX:type=VALUE
GRAPH:placement=0%x0%+100%x50%:xaxis=1:yaxis=1:ylabellocation=left:xlabellocation=bottom
GRAPH:placement=0%x0%+100%x50%:xaxis=1:yaxis=2:ylabellocation=right:xlabellocation=hidden
GRAPH:placement=0%x50%+50%x100%:xaxis=2:yaxis=3:ylabellocation=left:xlabellocation=top
GRAPH:placement=50%x50%+100%x100%:xaxis=3:yaxis=4:ylabellocation=right:xlabellocation=hidden
GRAPH:placement=50%x50%+100%x100%:xaxis=3:yaxis=5:ylabellocation=hidden:xlabellocation=bottom
LINE:vname=data1:xaxis=1:yaxis=1:label=data1:color=...
LINE:vname=data2:xaxis=1:yaxis=2:label=data2:color=...
LINE:vname=data3:xaxis=2:yaxis=3:label=data3:color=...
LINE:vname=data3:xaxis=3:yaxis=4:label=data4:color=...
LINE:data3#ff00ff:data4:xaxis=3:yaxis=4 # to show the old positional parser is still working...
You also see that I would like to be able to use VDEFs to control MIN/MAX of an axis (and use implicit VDEFS for defaults)
Also we should be able to set the type of an axis to value or time, so that we can create different types of graphs.
What also came to my mind is the possibility to decide if we want to print/graph something depending on a vdef (say by LINE:vname=data3:...:if=data,MAX,20,LT - also for gprint or such)
Then we could graph high and low volume data in 2 graphs top/bottom and see any abnormalies in any of those lines.
To implement all this it would obviously make life much easier with some object-orientated design at its base...
Adding another type of chart (say PIE or Histogram) may then be as easy as writing a custom library that gets dynamically loaded...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20120306/93a6d08a/attachment.htm
More information about the rrd-developers
mailing list