[rrd-users] [rrd-developers] [PATCH + RFC] Cleanup the symbols exported by librrd.

[Bernhard Fischer]

On Sun, Jun 08, 2008 at 04:46:50PM +0200, Sebastian Harl wrote:
>Hi,
>
>(Cc'ing rrd-users, hoping to get more feedback!)
>
>Please find attached a patch which cleans up the symbols exported by
>librrd (and librrd_th). See the patch description for a detailed
>changelog (I hope I didn't miss anything) and a short rationale for the
>patch. I'm sorry that the patch got that long but I had to touch a lot
>of places to implement all changes I wanted to do and keep things still
>compiling ;-)
>
>I would really like to see this patch in the upcoming 1.3 release, so
>further feedback would be very appreciated. So far, I did not do a lot
>of testing but I'm going to recompile all reverse dependencies of
>rrdtool (i.e. packages which build-depend on rrdtool) which can
>currently be found in Debian unstable and report back after that.
>However, I'm not going to be able to do much functional testing, so
>that's up to you - the users of those packages! ;-)
>
>While creating the patch, I noticed a couple of things which I would
>like some more opinions about:
>
> * Currently, librrd and librrd_th export the same set of symbols (e.g.
>   both libraries export the thread-unsafe rrd_fetch() as well as the
>   thread-safe rrd_fetch_r()). Is this intended? If not, I guess this
>   should be changed before 1.3 as well as that would else require
>   another SONAME bump.
>
> * I did not include rrd_open(), rrd_close(), rrd_write() and similar
>   functions in the public interface so far as they look like pretty
>   low-level functions which usually are not needed outside of rrdtool.

These functions should be exported since any librrdtool is pretty
useless without them.

Suppose i want to write a program that opens an rrd and reads one or
more DS and a varying number of entries from some CF, calculates
something and returns a result. Currently i would have to do alot of
what fetch does to achieve this, which doesn't make sense in the light
of a librrdtool.
See
http://www.mail-archive.com/rrd-developers@lists.oetiker.ch/msg01866.html