[rrd-users] Re: No step function

[Owen DeLong]

> well there are two things, first you would have to create a new ds
> type because the internal calculation for gauge does work with this
> step aproach ... 
> 
I don't think that's really necessary.  I think the key element
here is how the points are connected on the graph, not how they
are stored in the ds.

> second you might want to create new functionality for rrdgraph for
> somehos specifying how to draw ... (connect dots, stair, polymon,
> ... ) this should them be customizable for each LINEx and AREA
> operator ... (aargh)
>
I don't have the math/software development skills to implement this (or
the time), but how about something like:

	LINEx:ds[#color][/method]:description

If /method was missing, it would default to step.  With a little thought,
it should be possible to create an API for "methods" to be registered in
a shared library so that people could fairly easily add methods without
involving alot of integration with the rest of the guts of RRDgraph.

In this way, it would be fairly easy to implement the following methods
immediately:
		step
		dots
		connect

And, people with more time (and math skills) on their hands could implement
things like:
		curve-fit
		smooth
		etc.

I'm thinking that the API could be something like a function call to the
method with arguments of xmin, xmax, xstep, y[].  Then, the function
could return length, x[],y[].  This would allow the function to return
any number of (x,y) coordinates back to the plotting functions.  The
simplest function would be connect, which would simply return an array
of x[] ranging from xmin to xmax at xstep, and including the original
y[] array.  Replicating the current functionality would consist of
returning two copies of each x value, one with the previous y[] value,
and one with the current y[] value.

Since this would be expressed in graph coordinates and the values would
already have been scaled, no effort is really required for coping with
origin or scaling in the API.  It can simply be assumed that the coordinate
system originates at 0,0.  As such, y[n]=-1 can be used to represent NaN
conditions.  Any returned y[n] of -1 would result in an effective "pen
up" on the plot function.

I haven't looked at the RRD code, so I don't know how easy it would be
to add this, but I suspect that there's probably a point in the code
where you have a list of y values ready to plot.  If that's so, I think
it might be fairly easy.

Owen

> cheers
> tobi
> 
> *> TIA
> *> 
> *> Joe Loiacono                             Phone: (301) 794-2509
> *> NISN Network Engineering                 Fax:   (301) 794-9480
> *> Computer Sciences Corporation      Goddard Space Flight Center
> *> 
> *> --
> *> Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
> *> Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
> *> Archive     http://www.ee.ethz.ch/~slist/rrd-users
> *> 
> 
> -- 
>  ______    __   _
> /_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
>  / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518 
> /_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker
> 
> --
> Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
> Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
> Archive     http://www.ee.ethz.ch/~slist/rrd-users
> 
> 

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-users