[rrd-developers] exporting cf_conv

[Bernhard Reutner-Fischer]

On Wed, May 27, 2009 at 08:25:32PM +0200, Bernhard Reutner-Fischer wrote:
>On Tue, May 26, 2009 at 01:42:57PM +0200, Tobias Oetiker wrote:
>>Hi Bernhard,
>>
>>Today Bernhard Reutner-Fischer wrote:
>>
>>> On Tue, May 26, 2009 at 09:17:59AM +0200, Tobias Oetiker wrote:
>>>
>>> >finally getting ready to publish 1.4rc I have resolved the
>>>
>>> btw.. Can we please have cf_conv exported since otherwise
>>> it is not really possible to do anything useful with the
>>> library.
>>
>>:-) interesting notion ... you mean all uses of the library up to
>>now have not been useful ?
>
>I don't know, but my usecase needs it exported from the beginning.
>I admit that i have _no_ idea how other users of the library
>look like, but i wouldn't be surprised if they were just using
>some high-level view without having to worry about performance :)
>>
>>please elaborate.
>
>Suppose i want to get some values out of an rrd (like i mentioned before
>in the sample-code here ¹) in the _fastest_ possible way and you have an
> rrd with say X ds and Y cf and only want to get ds_something with cf
>LAST, then you somehow need to get at the appropriate data.
>
>Note, that i cannot afford to waste any unwarranted cycles to get at that
>data, so high-level scripting languages and stuff like that are a nono,
>I have to rrd_open() the file, get at the data and interpret the values
>often, very often and as fast as possible. Since i need only current
>data in 99.9% of the accesses (and no older data), it of course helped
>to also keep the "hot" regions in memory as much as possible. But anyway.
>
>I would be more than happy to be able to reuse more of the existing
>code of librrd as you can see about all except the setup and reporting
>in the sample application is just taken 1:1 from rrd_fetch() (IIRC).
>
>See?
>
>¹)
> http://www.google.at/search?hl=en&num=50&q=rrd_reader&btnG=Search

I've put my current incarnation here, fyi:
wget -cN http://busybox.net/~aldot/rrdtool/rrd_reader.{c,h} && \
gcc -O2 $CFLAGS -o rrd_reader rrd_reader.c -I/opt/rrdtool/include

rrdtool-1.4, user-friendly C API, platform independent format sound
somehow familiar :)
If you're thinking about doing an 1.4-rc, then i encourage you to
look at the sample user above. Ideally, such a thing would just
consist of (quote from ¹ above):
---8<---
You can see how i had to:
a) duplicate basically all of rrd_format.h
b) had to duplicate those parts of fetching values that deal with the
calculation of the locus of the data we need.


The applet should basically do this instead:
0) [APP] option handling
1) call rrd_open()
2) [APP] eventually inspect the header.
3) [APP] setup desired start, end, step.
4) call rrd_find_rra() or rrd_find_best_rra() /* or however it would be
   called */
5) [APP] adjust start, end, step to legit values.
6) call rrd_fetch_fn()
7) [APP] rrd_close(); rrd_free()
8) [APP] do something with the results and exit.

Where stuff marked with [APP] is ok to be done by the application, but
the rest (points 1, 4, 6) should be just simple calls into librrd. 
---8<---
http://www.nabble.com/-PATCH-%2B-RFC--Cleanup-the-symbols-exported-by-librrd.-tt17719839.html#a17732207

cheers,
Bernhard