Re: Demo: RRD - Web 2.0 style

Hi Peter,

Today Peter Stamfest wrote:
> > 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.

ah ... yes ... I would suggest to have a tooltip come one as the
cursor slides over the chart, to show the selected time and value
...

> > >
> > > 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

yes

> 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.

I was thinking about preprocessing the data on the server and then
sending it to the client ... this would help with keeping the
amount of data at bay.

cheers
tobi

>
> peter
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch [email protected] ++41 62 775 9902 / sb: -9900