<br><tt><font size=2>Tobias Oetiker <tobi@oetiker.ch> schrieb am
14.10.2010 07:28:15:<br>
<br>
> Hi Peter,<br>
> <br>
> Yesterday Peter Stamfest wrote:<br>
> <br>
> > Tobias Oetiker <tobi@oetiker.ch> schrieb am 13.10.2010
23:09:45:<br>
> ><br>
> > > Today Peter Stamfest wrote:<br>
> > ><br>
> > > > Hi everybody!<br>
> > > ><br>
> > [...]<br>
> > > ><br>
> > > > Has this been done before?<br>
> > ><br>
> > > yep ... that was about the state I was at as well when I
was<br>
> > > hacking this last time ... got side tracked though ... :-(<br>
> > ><br>
> > > in any event, things should be simpler now since the graphv<br>
> > > interface gives lots of 'sensible' information and could
also be<br>
> > > easily enhanced to give more info if required.<br>
> ><br>
> > This actually *is* using graphv. And as I said, the major pain
was the<br>
> > missing absolute time frame in the generated picture.<br>
> <br>
> I thought graph_start and graph_end to be useful for this ...<br>
</font></tt>
<br><tt><font size=2>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*.</font></tt>
<br>
<br><tt><font size=2>And this was the major problem, because the rest was
so ... simple.</font></tt>
<br>
<br><tt><font size=2>> ><br>
> > I'm unsure what kind of support would be needed to enhance responsibility:<br>
> > It might make sense to somehow keep data ready for graphing multiple<br>
> > times, but I am unsure about a usable interface in order to keep
rrdtool<br>
> > and this web 2.0 thing separate...<br>
> <br>
> I would have two graphs ... a wide long one below and the detail<br>
> one above ...<br>
</font></tt>
<br><tt><font size=2>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:</font></tt>
<br>
<br><tt><font size=2>- time resolution for an entire graph always is determined
by the lowest time resolution in any part of the graph</font></tt>
<br><tt><font size=2>- vertical resolution depends on the difference between
highest and lowest value (mod command line settings)</font></tt>
<br><tt><font size=2>- time axis labelling would be a real pain as well</font></tt>
<br>
<br><tt><font size=2>Before settling for the use of rrdtool for graphing,
I investigated some client-side only approaches (using things like </font></tt><a href="http://www.simile-widgets.org/"><tt><font size=2>http://www.simile-widgets.org/</font></tt></a><tt><font size=2>),
but that didn't work very well.</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>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.
</font></tt>
<br>
<br>
<br><tt><font size=2>peter</font></tt>
<br>