[rrd-developers] Suggestion for API extension

[Dan Cech]

Benny Baumann wrote:
> Though rrdtool_info will need some cleanup too. Simply returning an
> array will all the needed values should be sufficiant and much more
> practical.

This is an interesting BC question, all the updates I've made so far are
completely backwards compatible, not requiring any changes to existing
code using the extension.  Changing the rrdtool_info function to return
an array rather than printing the information is a pretty major change.

The rrd_fetch output presents a similar problem, all the values are
returned in a single long array at present.  It would be nice to return
the data as a multi-dimensional array with each 'row' of data grouped
together (and very simple to do in the extension) but it would break BC
with existing scripts using the current version of this function.

>> I was planning to tackle rrd_info next, but haven't looked at rrd_dump.
>>   
> I already completed rrd_info, but didn't parse the returned key names.
> I'm writing a PHP wrapper for this PHP extension and as such I can do
> parsing of the keynames there.

Yeah, returning the raw data as it comes from rrd_info_r is easy, but I
was planning to parse it out into a multi-dimensional php array.  A
separate php-code library to parse the output of the rrd_info function
in the php extension seems like it would make it more difficult to use
the system because you would need to have the userland php code as well
as the extension itself.

> Some work on Open Basedir Restriction can be found at
> http://blog.benny-baumann.de/?p=352 (German). The patch there isn't
> fully up-to-date, bbut basically works (except for one minor typo I
> already fixed in my local dev version).

I hadn't considered open_basedir, but it seems like a good idea to add
this safety feature.  Enforcing open_basedir on the actual RRDs
referenced in graph, xport, etc will be more difficult though!

> Would be nice if we could exchange our versions to merge the changes,
> thus avoiding duplicate work.

Agreed, any suggestions on the best way to do that?

> What do you think of offering a callback based variant in addition to a
> file based variant thus programs that need the returned data in a buffer
> can grab it without needing to write to the filesystem?
> 
> Other functions (e.g. for rrd_graph) that write to disk might use such a
> callback too, or offer returning the ressources they created to the
> caller (i.e. giving the generated image as a internal ressource to the
> caller).

I can see how this might be a useful thing to support, in the case of
rrd_graph I was considering implementing and interface to graphv which
would allow returning the image data as a php string directly, but the
volume of data returned by rrd_dump can obviously be much larger than
the typical graph image.

I typically output the graph images to temporary files named according
to a hash of the graph arguments, which allows me to re-use graph images
for multiple clients without needing to regenerate them from the source
rrds (very useful when multiple clients are requesting identical graphs).

I'm no expert but it seems like the data will still all need to be
collected into a buffer before it can be returned to the calling php
script as a string or php array, so in the case of rrd_dump it may be
more efficient to write out the xml to disk and perform any operations
on it using a stream-based xml parser.

Dan

-- 
Dan Cech
Ubersmith, Inc.
http://www.ubersmith.com