henrik in what way is the rrd_graphv interface not sufficient for your purpose?
cheers Tobias Oetiker t...@oetiker.ch 062 775 9902 > On 17.02.2014, at 15:51, Henrik Størner <henrik-rrdus...@hswn.dk> wrote: > > Hi, > > I would like to propose an extension to the librrd API with a new function > similar to rrd_graph(), but instead of writing the generated image data to > stdout it will return it in a memory buffer back to the caller. > > My reason for this is two-fold: > > > 1) I am using librrd to generate graphs via a web CGI program. This really > has to be done like: > > - Output the HTTP headers, including a "Content-type: image/png" > - call rrd_graph() to generate the image > > If the rrd_graph() invocation fails for some reason, then it is not possible > to provide an error message to the user since the content type is already > fixed as a PNG image. So unless I can compose an error message in a PNG image > (a bit difficult), then the webpage just shows up with a broken image. > > > 2) I would like to use the FastCGI interface for speeding up web image > generation, but this requires that all output goes through the FastCGI output > routines. Since rrd_graph() simply does an fwrite() to stdout, it cannot be > combined with FastCGI. > > > Looking at the rrd_graph() and rrd_graph_v() code, I can see that the > generated image data is already contained in an "unsigned char" buffer. So > the amount of change needed to just return this buffer back to the caller is > minimal. > > To avoid an API change that breaks existing code, I think the best way is to > provide a new function - e.g. "rrd_graph_buffer()" - that returns the graph > data in a buffer, and keep the current rrd_graph() API unchanged. > > I have attached a patch against version 1.4.8 implementing this. The patch > implements the rrd_graph_buffer() via the C API; I am not sure of how to do > the various other language bindings, so those are not included. > > I hope this patch - or something with similar functionality - can be included > in a future rrdtool release. > > > Best regards, > Henrik > <rrd_graph_buffer.diff> > _______________________________________________ > rrd-users mailing list > rrd-users@lists.oetiker.ch > https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
