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

[Michael T. Babcock]

> I am not certain modifying data should be a part of the base
> functionality (it isn't now). Some of the efficiency aspects of RRDtool
> rely on the fact the data is inserted once and only once.

I'll accept that argument/concept as true.

> I am certainly in favor of enhanced "base" functionality. As an example,
> I would like to see update return a list (array) of the most recent
> values written to the lowest resolution RRA. Currently front-end tools,
> such as Cricket, have to issue a separate fetch to retrieve this data
> for purposes of applying monitoring thresholds. Such tools can't use the
> values passed to rrdtool because presumably they rely on (1)
> interpolation and (2) computing deltas (for DERIVE and COUNTER).

Can I get some idea, for the sake of wrapping my brain around what you're
saying, of what you would do now, and what you would prefer to do?
Preferably in pseudo-code / C++.

> Re: graphing as part of the tool vs. external. I don't think RRDtool
> (either version 1.0.x or 1.1.x) promises to be a replacement for
> full-featured graphing tools and libraries. Such tools can certainly be
> used, as Keith's script demonstrates. RRDtool provides limited graphing
> functionality optimized for time series data. Perhaps conceptually, pie
> charts shouldn't be included, but since they are already included (and
> without additional library dependencies), I'll take 'em.

Agreed; I wouldn't suggest _removing_ graphing from the rrdtool package,
just perhaps realising that adding rrdtool backends to other graphing
packages is perhaps more useful.  As you infered, had another graphing
package that supports pie charts been augmented to use rrdtool data, we
might be in the same / better place as we are now with rrdtool supporting it
itself.  I'm not sure adding pie charts to rrdtool is the best use of
resources (programming time) that could have been put into making really
nice graphing available through an external (preferably open source)
program, but that's up to those who do the work :-).

> Finally, I think the debate over graphing functionality can be separate
> from introducing xml syntax to augment the graph command (and yes, I
> prefer augment vs. replace).

I would appreciate some suggestions on making the XML syntax I suggested (or
others'?) as functional / extensible as possible before bothering to work on
parsing it.  I've discovered the hard way that a poorly defined XML schema
can give more hassles than not in the long run.

> Microsoft MSN

I'll forgive you :-P
--
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