[rrd-users] Re: Fix for Tcl binding

[Dave Bodenstab]

On Fri, 7 Oct 2005 09:22:04 +0200 (MEST) Tobias Oetiker <oetiker at ee.ethz.ch> wrote:

> > I wrote:
> >
> > 2.)
> >
> > I've messed with mailgraph and written a simple cgi using rrdtool.
> > What you need is an API that lets a perl/tcl/etc. binding get the
> > output of rrdgraph directly -- skip the file stuff.  After all, if
> > I have to write an image file and then turn around a read it so the
> > cgi can deliver the image to the client, why bother with a specialized
> > .so?  ...Just run the rrdgraph program.   Yes, I know it's a little
> > more efficient to load the .so once rather than run the program multiple
> > times... but it would be even better if the whole "writing the image
> > to a file" could be avoided in the first place.  It also avoids the whole
> > business of picking a suitable "tmp" directory.
> >
> > Even the other functions (rrdlast, rrdfetch, etc.) would be easier to
> > deal with if they did not insist on writing the result to stdout.
> >
> > I think providing some interface to avoid the "write to stdout" or
> > "write a file" would be appreciated by all who want to embed rrd.
> > Certainly with .png files, it's possible to capture the image without
> > writing a file; I haven't looked, but it can't be too hard for the
> > others.
>
> the api can already write to an arbitrary fd ... check out the code
> ...
>
> maybe this helps ...

A fd is just a file by another name. :-)

I think, with a couple of changes, rrdgraph would be much easier to
use in CGI.  I'm not sure this is worth a drawn out discussion, but
I'll try to make a case for adding one (or perhaps two) new API's
for rrdgraph:

 1. Return an in-memory image
 2. Return the X&Y dimensions of the image that would be created
    with a given set of parameters (this is trivial once the image
    exists in memory, it really depends on whether it's easier to
    compute the dimensions without generating an image or just
    generate a throw-away image and return the dimensions)

This would allow CGI's to avoid having to write the images to actual
files as an intermediate step before re-reading them and sending
them to the client.

As it stands now, a CGI must write the image to the file system
in order to (a) get the actual length for the Content-Length: header,
and (b) to put the "width=x height=y" in an image tag.

Item (b) can be done now, but it involves generating a throw-away image
just to get the x&y dimensions.  Item (a) cannot be done without writing
an actual file.

If there were an API to "get image dimensions of the graph that
would be generated if rrd_graph were called with these parameters"
then item (b) is done.  If rrd_graph could return an in-memory image,
then item (a) is done.  Perhaps it's not possible due to the font
rendering, etc. to get the image dimensions before actually rendering
the graph.  If so, then I guess a throw-away image might be the only
way to implement (b)... without benchmarking it, though, it's hard to
say if the cpu-time trade off versus the I/O overhead to write an
image file is better or worse.

My $.02

Anyway, in the spirit of "writing to an arbitrary fd", I've attached
another patch for tclrrd.c.  It allows a Tcl "channel id" to be
used as the first "filename" argument.  With this patch, Rrd::graph
checks the "filename" argument, and if it's a channel id writes the
image to that Tcl stream.  Tcl "puts" can then be intermingled with
Rrd::graph.  The result is that a CGI written using Tcl can do:

  puts "Content-type: image/png"
  puts ""
  Rrd::graph stdout ....

BTW, this did not work properly before unless one inserted a "flush
stdout" before a call to "Rrd::graph - ..." because of the I/O buffering
done by Tcl.

Dave Bodenstab



-- Attached file removed by Ecartis and put at URL below --
-- Type: application/octet-stream
-- Size: 1k (1208 bytes)
-- URL : http://lists.ee.ethz.ch/p/Patch2.gz


--
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://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi