Re: Demo: RRD - Web 2.0 style

Tobias Oetiker <[email protected]> schrieb am 14.10.2010 07:28:15:

> Hi Peter,
> 
> Yesterday Peter Stamfest wrote:
> 
> > Tobias Oetiker <[email protected]> schrieb am 13.10.2010 23:09:45:
> >
> > > Today Peter Stamfest wrote:
> > >
> > > > Hi everybody!
> > > >
> > [...]
> > > >
> > > > Has this been done before?
> > >
> > > yep ... that was about the state I was at as well when I was
> > > hacking this last time ... got side tracked though ... :-(
> > >
> > > in any event, things should be simpler now since the graphv
> > > interface gives lots of 'sensible' information and could also be
> > > easily enhanced to give more info if required.
> >
> > This actually *is* using graphv. And as I said, the major pain was the
> > missing absolute time frame in the generated picture.
> 
> I thought graph_start and graph_end to be useful for this ...

This is a misunderstanding. I am using graph_start and graph_end. It is 
just that in a standard image, you never know if "13:20" refers to 
2010-10-13 or 2005-09-27 *visually*.

And this was the major problem, because the rest was so ... simple.

> >
> > I'm unsure what kind of support would be needed to enhance 
responsibility:
> > It might make sense to somehow keep data ready for graphing multiple
> > times, but I am unsure about a usable interface in order to keep 
rrdtool
> > and this web 2.0 thing separate...
> 
> I would have two graphs ... a wide long one below and the detail
> one above ...

I thought about an approach where the server would generate a longer graph 
once and many move requests would access this image and rearrange slices 
from it into a new graph, but this has *many* problems:

- time resolution for an entire graph always is determined by the lowest 
time resolution in any part of the graph
- vertical resolution depends on the difference between highest and lowest 
value (mod command line settings)
- time axis labelling would be a real pain as well

Before settling for the use of rrdtool for graphing, I investigated some 
client-side only approaches (using things like 
http://www.simile-widgets.org/), but that didn't work very well.

The current approach has the advantage that it might be "clouded": Just 
add more CPU power to RRD graphing and motion gets smoother. One might 
also "precreate" intermediate images.

Another possibility would be to translate all of rrdgraph into javascript 
and use an HTML canvas, accessing the RRD data through AJAX. I think this 
is what will happen in the long run..... but it would expose raw RRD data 
to the world, something that is often not really wanted. 


peter

_______________________________________________
rrd-developers mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers